Event-Driven vs. Scheduled Automation: Mastering Jenkins "Hello World!" with GitHub Webhooks and Polling

Namaste Folk! 🙏 Your guide to seamless automation is back, and today we're diving into the fascinating world of triggering Jenkins Freestyle Jobs. We'll explore two powerful mechanisms for automatically starting your builds: GitHub hook trigger for GITScm polling (driven by events) and Poll SCM (driven by a schedule).

Using our trusty "Hello World!" Freestyle Job as an example, we'll walk through the step-by-step configuration of each trigger, clearly differentiate their functionalities, and highlight their ideal use cases. Understanding these triggers is crucial for building efficient and responsive CI/CD pipelines right here in our vibrant tech hub.

Our Familiar Friend: The "Hello World!" Freestyle Job

As a quick refresher, our "Hello World!" Freestyle Job is a simple task that prints "Hello World!" to the Jenkins console. We'll assume you have this job created. If not, here's the quick setup:

1. New Item: Create a new Freestyle project named HelloWorldWebhook and HelloWorldPoll.

2. Build Step: Add an "Execute shell" step (for Linux/macOS agents) or "Execute Windows batch command" (for Windows agents) with the command echo "Hello World!" (or echo Hello World! for batch).

3. Save: Save the job configuration.

Or for detailed guide visit Setup "Hello World" - Free Style Job

Now, let's explore the two trigger mechanisms.

Trigger 1: GitHub hook trigger for GITScm polling - Reacting to GitHub Events

This trigger allows your Jenkins job to automatically start a build whenever specific events occur in your GitHub repository, such as pushing new code. It's an event-driven approach, making your CI/CD pipeline highly responsive to changes.

Step-by-Step Configuration:

1. Open Job Configuration: Navigate to your HelloWorldWebhook job and click "Configure".

2. Source Code Management (SCM):

   • Ensure you have configured your Git repository details correctly (Repository URL, Credentials if needed, and the Branch to build). For demonstration purposes, I've used a public repository. If you're working with private repositories, make sure to configure the necessary credentials. Feel free to share any feedback or suggestions in the comments.

3. Build Triggers:

   • Check the box next to "GitHub hook trigger for GITScm polling".

   • You might see a note about needing to configure your GitHub repository. We'll get to that shortly.

4. Save Configuration: Click "Save".

Setting up the GitHub Webhook:

For this trigger to work, you need to configure a webhook in your GitHub repository that notifies your Jenkins server whenever relevant events occur.

1. Go to your GitHub Repository: Open your repository on the GitHub website.

2. Navigate to Settings: Click on the "Settings" tab.

3. Go to Webhooks: In the left-hand sidebar, click on "Webhooks".

4. Add a new webhook: Click the "Add webhook" button.

5. Payload URL: Enter the URL of your Jenkins server followed by /github-webhook/. For example, if your Jenkins server is running at http://your-jenkins-ip:8080, the Payload URL would be http://your-jenkins-ip:8080/github-webhook/. Note: Ensure your Jenkins server is reachable from GitHub (you might need to configure port forwarding or use a service like ngrok for local setups).

6. Content type: Choose application/json.

7. Secret (optional but highly recommended): Set a secret. This helps ensure that the webhook requests are actually coming from GitHub. Copy this secret, and in your Jenkins job configuration (under "GitHub hook trigger for GITScm polling"), click the "Advanced..." button and enter the same secret.

8. Which events would you like to trigger this webhook? You can choose specific events or select "Just the push event" for triggering builds on new code pushes. You can customize this based on your workflow.

9. Active: Ensure the "Active" checkbox is selected.

10. Add webhook: Click the "Add webhook" button.

    

    

Now, whenever you push new code to the branch configured in your Jenkins job, GitHub will send a webhook event to your Jenkins server, which will then trigger the HelloWorldWebhook job automatically.

Console output:

Use Case for GitHub Webhook Trigger:

• Continuous Integration (CI): Ideal for automatically building and testing your code every time a developer pushes changes to the repository. This provides immediate feedback on the health of the codebase.

• Highly Responsive Pipelines: Ensures that builds are triggered instantly upon code changes, leading to faster iteration cycles.

Trigger 2: Poll SCM - Regularly Checking for Changes

The Poll SCM trigger takes a different approach. Instead of waiting for an external event, Jenkins periodically checks your configured Source Code Management (SCM) repository for any changes. If changes are detected since the last build, Jenkins will trigger a new build. This is a schedule-based approach.

Step-by-Step Configuration:

1. Open Job Configuration: Navigate to your HelloWorldPoll job and click "Configure".

2. Source Code Management (SCM):

   • Ensure you have configured your Git repository details correctly (Repository URL, Credentials if needed, and the Branch to build). For demonstration purposes, I've used a public repository. If you're working with private repositories, make sure to configure the necessary credentials. Feel free to share any feedback or suggestions in the comments.

     

3. Build Triggers:

   • Check the box next to "Poll SCM".

   • In the "Schedule" text area, enter a cron expression that defines how often Jenkins should poll your SCM. For example, to poll every minute, you would enter * * * * *. To poll every 2 minutes, you would use H/2 * * * *. Refer to our previous article on periodic builds for a detailed explanation of cron syntax.

     

4. Save Configuration: Click "Save".

Jenkins will now periodically check your Git repository according to the schedule you defined. If it detects any new commits on the configured branch since the last build, it will automatically trigger a new build of the HelloWorldPoll job.

Console output:

Use Cases for Poll SCM:

• Environments Where Webhooks are Not Feasible: In some restricted network environments or older SCM systems, setting up webhooks might not be possible or straightforward. Poll SCM provides an alternative.

• Scheduled Integration Checks: Even if you have webhooks configured, you might want to have an additional periodic poll as a fallback mechanism or to ensure consistency at regular intervals.

• Monitoring for External Changes: If your build depends on changes in a repository you don't directly control and webhooks aren't available, polling can be a solution.

Key Differences Summarized

Choosing the Right Trigger

The choice between "GitHub hook trigger" and "Poll SCM" depends on your specific needs and environment:

• For the most responsive and efficient CI pipelines with GitHub, "GitHub hook trigger" is generally the preferred method. It triggers builds only when necessary, saving resources and providing immediate feedback.

• If you cannot set up webhooks or prefer a scheduled approach, "Poll SCM" provides a reliable alternative. However, be mindful of setting an appropriate polling interval to balance responsiveness with resource usage. Polling too frequently can put unnecessary load on your SCM system and Jenkins server.

Conclusion: Empowering Your Automation with Intelligent Triggers

Mastering these Jenkins trigger mechanisms empowers you to automate your workflows intelligently. Whether you choose the real-time responsiveness of GitHub webhooks or the scheduled reliability of Poll SCM, understanding their nuances is key to building effective CI/CD pipelines here in the heart of Bengaluru's tech scene and beyond.

Experiment with both triggers for your "Hello World!" job and observe how they behave. This hands-on experience will solidify your understanding and prepare you to tackle more complex automation challenges. Keep exploring, keep automating, and keep building amazing things!