Jenkins Build Triggers and Scheduling
A build trigger tells Jenkins when to start a job. Without triggers, every build requires a human to click a button. Triggers remove that dependency and make your pipeline truly automatic.
Think of a build trigger as the alarm clock that wakes up Jenkins. You set the conditions once, and Jenkins wakes up and gets to work without you asking every time.
Types of Build Triggers
Jenkins supports several trigger types. Each one answers the question: "What event should start this build?"
Trigger Overview Diagram
WHAT STARTS A JENKINS BUILD?
[Developer pushes code]
↓
GitHub Webhook ──────────────→ Jenkins starts build
[Scheduled time arrives]
↓
Build Periodically ──────────→ Jenkins starts build
[Jenkins checks Git on a timer]
↓
Poll SCM ────────────────────→ Changes found? → Jenkins starts build
No changes? → Wait and check again
[Another job finishes]
↓
Build After Other Project ───→ Jenkins starts build
[External system calls URL]
↓
Remote Trigger ──────────────→ Jenkins starts build
[Human clicks button]
↓
Manual Trigger ──────────────→ Jenkins starts build
Trigger 1: Build Periodically (Scheduled Builds)
This trigger runs the job on a fixed schedule, similar to a cron job on a Linux server. You define the schedule using cron syntax.
Cron Syntax for Jenkins
Format: MINUTE HOUR DAY_OF_MONTH MONTH DAY_OF_WEEK Examples: H/15 * * * * → Every 15 minutes 0 6 * * * → Every day at 6:00 AM 0 8 * * 1-5 → Monday to Friday at 8:00 AM 0 0 * * 0 → Every Sunday at midnight H H(0-7) * * * → Once per night between midnight and 7 AM
The H symbol is special in Jenkins. Instead of running all jobs at exactly the same second (which overloads the server), Jenkins spreads them out using H as a hash-based offset. Think of it as Jenkins politely staggering appointments rather than having everyone arrive at the exact same time.
Trigger 2: Poll SCM
Poll SCM tells Jenkins to regularly check the Git repository for changes. If it finds new commits since the last build, it starts a build. If no changes exist, it does nothing.
Example: Poll every 5 minutes H/5 * * * * Jenkins behavior: Check time Git changes? Action 12:00 No Do nothing 12:05 No Do nothing 12:10 Yes (new commit) → START BUILD 12:15 No Do nothing
Poll SCM is simple but not ideal for busy teams. Jenkins keeps checking even when nothing happens, which wastes resources. Webhooks (below) are more efficient.
Trigger 3: GitHub / Git Webhook (Recommended)
A webhook is a message GitHub (or any Git server) sends to Jenkins the moment code is pushed. Jenkins does not check for changes — GitHub tells Jenkins when changes happen.
Imagine the difference between checking your mailbox every hour (Poll SCM) versus having the mail carrier ring your doorbell when they arrive (webhook). Webhooks are faster and more efficient.
How to Set Up a GitHub Webhook
In GitHub: 1. Open your repository 2. Go to Settings → Webhooks → Add webhook 3. Payload URL: http://your-jenkins:8080/github-webhook/ 4. Content type: application/json 5. Trigger: "Just the push event" or "Let me select individual events" 6. Click "Add webhook" In Jenkins: 1. Open the job configuration 2. Under Build Triggers 3. Check: "GitHub hook trigger for GITScm polling" 4. Save
Trigger 4: Build After Other Projects Are Built
This trigger chains jobs together. When Job A finishes successfully, Jenkins automatically starts Job B.
Use case: A microservices team build-service-auth ──→ (on success) → deploy-service-auth build-service-api ──→ (on success) → run-integration-tests You configure this in Job B: Build Triggers → "Build after other projects are built" Projects to watch: build-service-auth Trigger when: Stable (success only)
You can trigger a downstream job when the upstream job succeeds, fails, or finishes regardless of result.
Trigger 5: Remote Trigger
The remote trigger lets an external system start a Jenkins job by calling a URL with a security token.
In Jenkins job configuration: Build Triggers → Trigger builds remotely Authentication Token: my-secret-token-123 Trigger URL: http://your-jenkins:8080/job/my-job/build?token=my-secret-token-123
This is useful when another system (a deployment tool, a monitoring alert, a custom script) needs to start a Jenkins job programmatically.
Trigger 6: Manual Build (Build Now)
The simplest trigger — a human clicks "Build Now" on the job page. Use this for on-demand runs, for testing a new job, or for jobs that should not run automatically.
Quiet Period
The quiet period delays a build start by a few seconds after a trigger fires. This prevents Jenkins from running multiple builds when several commits arrive in rapid succession.
Scenario without quiet period: Commit 1 at 10:00:00 → Build #1 starts immediately Commit 2 at 10:00:02 → Build #2 starts immediately Commit 3 at 10:00:04 → Build #3 starts immediately Result: 3 builds for changes that could be covered by 1 Scenario with 10-second quiet period: Commit 1 at 10:00:00 → Wait 10 seconds Commit 2 at 10:00:02 → Reset 10-second timer Commit 3 at 10:00:04 → Reset 10-second timer 10:00:14 → Build #1 starts (covers all 3 commits) Result: 1 build
Concurrent Build Control
By default, Jenkins allows a job to run multiple times simultaneously. If builds take a long time, this can cause conflicts — two builds modifying the same files at once. Check "Do not allow concurrent builds" in the General section to prevent this.
Key Points
- Build triggers control when Jenkins starts a job automatically.
- Use webhooks for instant builds when code is pushed — they are faster and more efficient than Poll SCM.
- Build periodically runs jobs on a time schedule using cron syntax.
- Use "Build after other projects" to chain jobs together automatically.
- The quiet period prevents duplicate builds when multiple commits arrive quickly.