Poll SCM Vs. Webhook to automate build-triggers | Overview.

 An Overview of Poll SCM Vs. Webhook to automate build-triggers 

Focus,

• Tailored for DevOps.

Breakdown:

• Intro,
• Comparison table for Poll SCM & Webhook to automate build-triggers, 
• Recommendation,
• Using the Poll SCM to automate build-triggers,
• How to set up Poll SCM to automate build triggers,
• Cron Syntax,
• Example cron expression,
• How Poll SCM works,
• Using webhook for Jenkins automation,
• How to set up webhook to trigger Jenkins builds,
• Advantages of Webhooks over Poll SCM,
• Troubleshooting,
• Troubleshooting webhook when it fails to trigger.

Intro:

• Both polling SCM and webhooks automate build triggers, but webhooks are generally considered a more efficient and modern solution

Comparison table for Poll SCM & Webhook to automate build-triggers, 

Feature	Polling SCM	Webhook
Trigger Mechanism	The CI server periodically checks the source code management (SCM) system for changes .	The SCM system (e.g., GitHub, GitLab) instantly notifies the CI server via an HTTP callback when a change occurs .
Efficiency	Inefficient, as most requests are to an unchanged repository .	Highly efficient, as notifications only occur when necessary .
Latency	Delay is dependent on the polling interval; changes are not immediately detected .	Instantaneous; builds are triggered immediately after a commit.
SCM Server Load	Higher, due to frequent, repetitive checks .	Lower, as the SCM only sends a notification when a push event happens .
Configuration	Easy to configure within the CI server settings (e.g., Jenkins).	Requires configuration in both the SCM and the CI server .

Recommendation:

• Webhooks are the superior choice for most modern development workflows due to their immediate feedback loop, reduced server load, and increased efficiency.
•  Polling SCM is only typically used when a webhook configuration is not possible (e.g., an old firewall blocking inbound requests to the CI server).
• twtech can find documentation on setting up these integrations in common CI/CD tools, such as the Jenkins Handbook on using SCM polling or general guides on configuring webhooks for services like GitHub or GitLa

Using the Poll SCM to automate build-triggers

• Using the Poll SCM feature in Jenkins allows you to automate the triggering of builds based on changes in your source code repository (such as Git). 
• This is useful for continuous integration (CI) pipelines, as it ensures that builds are automatically triggered whenever there are updates to the repository.

How to set up Poll SCM to automate build triggers

Steps-by-Step

1. Open Jenkins Dashboard:

   • Log in to your Jenkins instance and go to your desired job or create a new one.

2. Configure Job:

   • Select the job you want to configure and click Configure on the left sidebar.

3. Set Up Source Code Management (SCM):

   • Under the Source Code Management section, select the repository you want to use (e.g., Git, SVN).
   • Provide the necessary repository URL and credentials if required.

4. Enable Build Triggers:

   • Scroll down to the Build Triggers section.
   • Check the box for Poll SCM.
   • In the text field, enter a cron-like expression. This expression tells Jenkins how often to check for changes in the SCM repository.

   Example:

H/5 * * * *   Polls every 5 minutes.
H/15 * * * *  Polls every 15 minutes.
* * * * *     Polls every minute (not recommended for high load). 

 

NB:

•  H in the expression helps distribute the load across Jenkins instances by avoiding simultaneous polling on every job at the same time.

     5. Save Configuration:

• After configuring the SCM and Poll SCM settings, click Save to apply the changes.

Cron Syntax

Jenkins uses cron syntax for scheduling tasks. Here's a breakdown of the components:

• Minute (0 - 59)
• Hour (0 - 23)
• Day of month (1 - 31)
• Month (1 - 12)
• Day of week (0 - 6) (Sunday to Saturday)

Example cron expression

• H/5 * * * *    Polls every 5 minutes, with the job randomly starting at minute 0, 5, 10, 15, etc.

How Poll SCM works

• Once configured, Jenkins will periodically check the repository for any changes based on the cron schedule.
• If any changes (commits) are found, Jenkins will trigger a build automatically.
• If no changes are detected, the build won't be triggered.

NB:

This method is commonly used for repositories that are not integrated with webhooks or when you want more control over when builds are triggered.

 Using webhook for Jenkins automation

• Using a Webhook in Jenkins for automation is a great way to trigger builds in response to events in your source code repository (like commits or pull requests).
• Instead of polling your SCM (like with Poll SCM), webhooks let Jenkins know immediately when there's a change in the repository, making it a more efficient solution.

How to set up a webhook to trigger Jenkins builds

Step-by-step

1. Create or Configure a Jenkins Job

• Open your Jenkins dashboard.
• Either create a new job or configure an existing one.
• Go to the Configure section of the desired Jenkins job.

2. Configure Source Code Management (SCM)

• Under Source Code Management, choose the SCM you are using (e.g., Git).
• Provide the repository URL and credentials as needed.

3. Enable Build Triggers (Webhook Setup)

• Scroll down to the Build Triggers section.
• Check the GitHub hook trigger for GITScm polling (for GitHub repositories) or select the appropriate webhook trigger for your SCM.

4. Install Necessary Plugins

• Make sure you have the necessary plugins installed in Jenkins, like:
  • GitHub Plugin (for GitHub webhooks)
  • GitLab Plugin (for GitLab webhooks)
  • Bitbucket Plugin (for Bitbucket webhooks)

NB:

twtech needs to check and install plugins by navigating to Manage Jenkins → Manage Plugins → Available and search for the relevant plugin.

5. Generate Jenkins Webhook URL

• Once twtech has enabled the appropriate webhook trigger, Jenkins will provide twtech with a URL.
  • The URL format will look like this:

    # perl
    
    http://<twtech-jenkins-domain>/github-webhook/
    

  • This is the endpoint that twtech will configure in its source code repository.

6. Configure Webhook in twtech Source Code Repository

• GitHub:

  • twtech Goes to the GitHub repository that it wants to link to Jenkins.
  • Navigate to Settings → Webhooks → Add webhook.
  • In the Payload URL field, enter the Jenkins webhook URL (http://<twtech-jenkins-domain>/github-webhook/).
  • Set the Content type to application/json.
  • Choose which events should trigger the webhook, for example, Push events, Pull requests, etc.
  • Click Add webhook.

7. Test the Webhook

• After setting up the webhook, make a change in your repository (like pushing a commit).
• Jenkins should automatically trigger a build when it receives the webhook notification from your repository.

Advantages of Webhooks over Poll SCM

• Real-time trigger: Webhooks send an immediate notification to Jenkins when a change occurs in your SCM (GitHub), avoiding the delay of polling.
• Efficient: No need for frequent polling, reducing load on Jenkins and the SCM server.
• Scalability: Better for handling large repositories and projects, as it scales well without overloading Jenkins with repeated checks.

Troubleshooting webhook when it fails to trigger

 If Jenkins doesn't trigger builds after setting up the webhook

• Check the Jenkins job logs for any errors.
• Verify the Webhook URL in your SCM settings. 
• Make sure it's correct and accessible by twtech SCM server.
• Test the webhook: Most platforms like GitHub and GitLab offer a "Test" button to simulate a webhook call and check the response.
• Ensure the necessary plugins are installed and up-to-date.