You are currently viewing Jenkins pipeline part 7 – triggers

Jenkins pipeline part 7 – triggers

Jenkins pipeline part 7 – triggers

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In today’s blog post, we will discuss triggers in a Jenkins pipeline and how to use different types of triggers in your Jenkins pipeline definition.

What is triggers is Jenkins pipeline?

The triggers directive defines the automated ways in which the Pipeline should be re-triggered. For Pipelines which are integrated with a source such as GitHub or BitBucket, triggers may not be necessary as webhooks-based integration will likely already be present. The triggers currently available are cron, pollSCM and upstream.

What are different types of triggers available in Jenkins:

There are different ways you can trigger a Jenkins pipeline. You can use API or script to trigger a pipeline, schedule the pipeline trigger with cron expression, on poll or push from a git-based repository like GitHub, trigger the pipeline from an upstream Jenkins pipeline or even disable the pipeline from getting triggered altogether.

Note: You can define a Jenkins trigger your project configuration or in the pipeline definition (topic of today’s blog).

Triggers that can be implemented on the project configuration:

Build after other projects are built:

Set up a trigger so that when some other projects finish building, a new build is scheduled for this project. This is convenient for running an extensive test after a build is complete. This configuration complements the “Build other projects” section in the “Post-build Actions” of an upstream project, but is preferable when you want to configure the downstream project.

Build periodically:

Provides a cron-like feature to periodically execute this project. This feature is primarily for using Jenkins as a cron replacement, and it is not ideal for continuously building software projects. When people first start continuous integration, they are often so used to the idea of regularly scheduled builds like nightly/weekly that they use this feature.

GitHub hook trigger for GITScm polling:

When Jenkins receives a GitHub push hook, GitHub Plugin checks to see whether the hook came from a GitHub repository which matches the Git repository defined in SCM/Git section of this job. If they match and this option is enabled, GitHub Plugin triggers a one-time polling on GITScm. When GITScm polls GitHub, it finds that there is a change and initiates a build. The last sentence describes the behavior of Git plugin, thus the polling and initiating the build is not a part of GitHub plugin.

Poll SCM:

Configure Jenkins to poll changes in SCM. Note that this is going to be an expensive operation for CVS, as every polling requires Jenkins to scan the entire workspace and verify it with the server. Consider setting up a “push” trigger to avoid this overhead.

Trigger builds remotely (e.g., from scripts):

Enable this option if you would like to trigger new builds by accessing a special predefined URL (convenient for scripts). One typical example for this feature would be to trigger new build from the source control system’s hook script, when somebody has just committed a change into the repository, or from a script that parses your source control email notifications. You’ll need to provide an authorization token in the form of a string so that only those who know it would be able to remotely trigger this project’s builds.

There are two additional option to configure trigger in Jenkins project configuration.

Disable this project:

When this option is checked, no new builds of this project will be executed. This can be helpful when you want to temporarily prevent a project from being built. For example, if your project depends on some infrastructure — e.g. a test server, or a source code repository — and you know it will be unavailable for a period of time, you could disable the project to prevent unnecessary build failures (and any corresponding notifications) during this period.

Quiet period:

When this option is non-zero, newly triggered builds of this project will be added to the queue, but Jenkins will wait for the specified period of time (in seconds) before actually starting the build.

Jenkins pipeline part 7 – triggers

Triggers that can be implemented on the Jenkins pipeline definition (Jenkinsfile):

cron:

Schedule your pipeline based on a cron style block which defines the trigger interval. This option is equivalent to “Build periodically” trigger option in Jenkins project trigger configuration.

pollSCM:

Accepts a cron-style string to define a regular interval at which Jenkins should check for new source changes. If new changes exist, the Pipeline will be re-triggered. This option is equivalent to “Poll SCM” trigger option in Jenkins project trigger configuration.

upstream:

Accepts a comma-separated string of jobs and a threshold. When any job in the string finishes with the minimum threshold, the Pipeline will be re-triggered. This option is equivalent to “Build after other projects are built” trigger option in Jenkins project trigger configuration.

Let’s dig down a bit with some examples.

Jenkins pipeline part 7 – triggers

Prerequisites

One system with Jenkins installed.

Jenkins pipeline – cron trigger example:

Create a new pipeline in your Jenkins controller server using below Jenkinsfile definition. Replace the label as per your Jenkins configuration.

Trigger the pipeline manually for the 1st time.

Jenkins pipeline part 7 – triggers

Observe, the pipeline gets triggered automatically after every one minutes.

Jenkins pipeline – pollSCM trigger example:

Update your Jenkinsfile hosted in a remote repository with below definition and then update the Jenkins project configuration to below –

Jenkins pipeline part 7 – triggers

Trigger the pipeline manually for the 1st time and then perform some changes in your git repository.

Jenkins pipeline part 7 – triggers

Observe, Jenkins checks your repository every one minute and if it detects any changes, Jenkins will checkout the new code and automatically trigger your pipeline.

Jenkins pipeline – upstream trigger example:

Create a new Jenkins project named “Jenkins_upstream”

with below Jenkinsfile and trigger the pipeline manually. This pipeline will serve as our upstream pipeline.

Currently we have two Jenkins project “jenkins” and “jenkins_upstream” and we are going to trigger the “jenkins” pipeline whenever “jenkins_upstream” pipeline gets successfully executed.

Jenkins pipeline part 7 – triggers

Now update the existing pipeline (jenkins) definition using the below Jenkinsfile and trigger the pipeline for the 1st time manually.

Jenkins pipeline part 7 – triggers

Observe, “jenkins” pipeline gets triggered every time your “jenkins_upstream” pipeline gets successfully executed. In this way you can trigger a Jenkins pipeline on the outcome of another Jenkins pipeline.

Hope you have enjoyed this article, to get more details on Jenkins, please refer below Jenkins official documentation.

https://www.jenkins.io/doc/

This Post Has One Comment

  1. Avatar
    Mickaël

    Hello,
    Thank you for the tutorial.
    Do you know if it is possible to combine different types of triggers for the same Jenkins declarative pipeline? For example, if I want the pipeline to be triggered by a cron and also by an upstream?
    Thank you by advance for your answer!

Leave a Reply