Jenkins – Part 3: Build Triggers, Scheduling and Job Chaining
In this article, I will explain different ways to trigger Jenkins jobs, how job chaining works, and how Jenkins manages multiple jobs in parallel.
1. Manual Builds
The most basic way to run a job in Jenkins is by clicking “Build Now.”
This means you, as a developer or DevOps engineer, go to the Jenkins dashboard, select the job, and hit the button.
Jenkins then starts the build immediately.
This method is simple and useful when:
You are testing a new job.
You are learning how Jenkins works.
You want to debug a failing build manually.
But this is not automation. In real-world pipelines, we rarely use manual builds except for special testing.
2. Build Periodically (CRON Scheduling)
Jenkins has an in-built scheduler that uses CRON syntax. This allows you to configure jobs that run at fixed intervals.
For example:
* * * * *→ Run every minuteH/30 * * * *→ Run every 30 minutes0 21 2 9 *→ Run at 9:00 PM on September 2
Advantages:
Good for periodic tasks like backups, cleanup scripts, or reports.
Easy to set up.
Disadvantages:
It does not care whether your code has changed or not. The job will run anyway.
For build jobs, this is wasteful because it may run multiple times with no new code.
This is why CRON is not the best option for continuous integration.
3. Poll SCM (Checking Git Repository for Changes)
This is a smarter option than CRON. Instead of running blindly at fixed times, Jenkins polls the source code repository (like GitHub or GitLab).
You can set Jenkins to check the repository every 5 minutes, 10 minutes, or any interval.
If Jenkins detects a new commit, it triggers the job.
If there is no change, the job does not run.
Advantages:
Builds run only when there are changes.
Saves time compared to CRON.
Disadvantages:
Jenkins still has to ask GitHub repeatedly, even if there is no new commit.
This increases load on Jenkins.
4. GitHub Webhook (Event-Driven Builds)
This is the most efficient method. Instead of Jenkins polling GitHub, GitHub itself notifies Jenkins whenever code is pushed.
Here’s the flow:
A developer commits and pushes code to GitHub.
GitHub immediately sends a webhook notification to Jenkins.
Jenkins receives it and triggers the job instantly.
Advantages:
Builds happen in real time.
No waste of resources.
This is the industry standard for CI/CD setups.
Webhooks make Jenkins reactive rather than repetitive. This is how you achieve true automation.
5. Job Chaining (Upstream and Downstream Jobs)
In real-world scenarios, one build step often depends on the result of another.
For example, a simple pipeline might look like this:
Job 1 – Pull code from GitHub
Job 2 – Run
mvn cleanto clean old buildsJob 3 – Run
mvn packageto build the projectJob 4 – Deploy the generated artifact to a Tomcat server
Here’s how job chaining works:
Job 2 is configured to run only after Job 1 succeeds.
Job 3 depends on Job 2.
Job 4 depends on Job 3.
This creates a chain of jobs that run in sequence, almost like dominos falling one after another.
Why it’s useful:
You can break down a large process into smaller jobs.
If one job fails, the chain stops there, so you don’t waste time running later steps.
It helps you structure your automation step by step.
Before Jenkins Pipeline DSL became popular, job chaining was the way to build pipelines. Even today, it is still useful for small setups.
6. Build Executors and Queue Management
Jenkins runs jobs using something called executors.
Each executor is like a worker that can run one job at a time.
If Jenkins has 2 executors, it can run 2 jobs in parallel.
If more jobs are triggered, they are placed in a queue and executed when an executor is free.
Why this matters:
On a small Jenkins server, you may have limited executors.
If too many jobs are triggered at the same time, they will queue up.
Configuring the right number of executors and agents ensures jobs don’t get delayed.
This is a simple but important part of Jenkins administration.