Running CI/CD jobs by hand is not a good method to start a pipeline process since everything done manually competes with automation. Jenkins provides various ways to start jobs automatically. These methods are categorized in the Build Triggers section. I will explain common pipeline trigger methods in this part of the Jenkins tutorial. Please note that some ways existed due to installing plugins and may not be found in Jenkins bare installations. So, I suggest you use the Jenkins stack has everything you need.
Jenkins supports various triggering methods, cron, webhook, URL, upstream, etc. All triggers should be defined in the triggers block of the pipeline.
cron is something like Unix/Linux cron. To write a cron trigger, use cron "MINUTE HOUR DOM MONTH DOW" syntax. You should note that more than one trigger can be defined for the same Jenkins pipeline job at the same time.
DOM is the Day Of the Month, and DOW is the Day Of the Week.
Here is a simple example:
cron "0 * * * *" runs at minute 0 of each hour.
cron "0 0 * * *" runs at 00:00 (once a day).
cron "0 0 * 2,4,6,8,10,12 *" runs once a day in even months.
cron "* 1-7 * * *" runs every minute from hour one through seven.
cron "*/10 * * * *" runs every 10th minute.
Important tip (H “hash” magic keyword): If you have a lot of jobs using triggers, for example, cron "0 0 * * *" It triggers all jobs at midnight, precisely at 00:00. Starting a multitude of jobs at the same time will put a lot of pressure on Jenkins and may cause it to fail. To solve this pressure, we can use the H symbol. This symbol tells Jenkins to use the hash model for the cron trigger. So, to solve our example, we can use cron "H H * * *" instead of cron "0 0 * * *". This cron will run the job once a day like the previous one, but not simultaneously with other jobs.
cron "H H * * *" runs once a day.
cron "H H(0-4) * * *" runs between 00:00 to 04:59 (once a day).
pollSCM accepts a cron-style pattern and looks for changes in your Git repository. The cron-style pattern is used to define the desired interval. You should note that it only works when the pipeline script is read from the SCM source.
The following trigger checks for changes in the Git repository every 10 minutes and runs the pipeline if any changes are detected.
upstream accepts a comma-separated list of upstream projects, and the current job will be triggered when any of them got completed. In addition to a list of projects, you can set the desired state of them, UNSTABLE, FAILURE, etc.
The default is SUCCESS build status.
Here is an example with a threshold:
hudson.model.Result.ABORTED: The build was manually aborted.
hudson.model.Result.FAILURE: The build had a fatal error.
hudson.model.Result.SUCCESS: The build had no errors.
hudson.model.Result.UNSTABLE: The build had an unstable result.
Jenkins Generic Webhook Trigger:
The Generic Webhook Trigger is a plugin that allows triggering pipelines through Webhook. This plugin helps integrate Jenkins with external applications like SCM, scripts, applets, etc., or setup a Webhook in GitHub, GitLab, etc.
To trigger the pipeline from the command line, run the following command:
The following pipeline checks for source changes every 10 minutes and runs when any changes are detected. It runs periodically every hour. It runs when the upstream project, my-base-project, is built successfully and can be triggered by the Webhook remotely by GitHub, etc., with the given token.
The end letter:
Build Triggers are very helpful in automating pipelines. The Generic Webhook Trigger is an awesome one. With triggers, we can create an extraordinary lifecycle for our environments and setup true automation properly.
You can find all tutorial materials in the following GitHub repository: