Triggers directive in Jenkins - Commands & Configuration

Introduction

Sometimes you want Jenkins to start a job automatically without clicking a button. The triggers directive helps Jenkins know when to start a job by itself based on events or schedules.

When you want a job to run every day at a specific time without manual start.

When you want Jenkins to start a build after a code change is pushed to a repository.

When you want to trigger a job after another job finishes successfully.

When you want to run a job periodically to check system health or run tests.

When you want to start a job based on external events like webhooks.

Config File - Jenkinsfile

Jenkinsfile

pipeline {
  agent any
  triggers {
    cron('H 2 * * *')
    pollSCM('H/15 * * * *')
  }
  stages {
    stage('Example') {
      steps {
        echo 'Job triggered automatically'
      }
    }
  }
}

The triggers block inside the pipeline tells Jenkins when to start the job automatically.

cron('H 2 * * *') runs the job once every day at 2 AM.

pollSCM('H/15 * * * *') checks the source code repository every 15 minutes and triggers the job if there are changes.

Commands

This command updates the Jenkins job with the Jenkinsfile that includes the triggers directive so Jenkins knows when to start the job automatically.

Terminal

jenkins-jobs --conf jenkins.ini update example-job

Expected Output

Job updated successfully

This command manually triggers the job to test that the Jenkinsfile and triggers are working correctly.

Terminal

jenkins-cli build example-job

Expected Output

Started build #1

This command shows the job configuration including the triggers to verify they are set correctly.

Terminal

jenkins-cli get-job example-job

Expected Output

<triggers>

  <hudson.triggers.TimerTrigger>

    <spec>H 2 * * *</spec>

  </hudson.triggers.TimerTrigger>

  <hudson.triggers.SCMTrigger>

    <spec>H/15 * * * *</spec>

  </hudson.triggers.SCMTrigger>

</triggers>

Key Concept

If you remember nothing else from this pattern, remember: the triggers directive tells Jenkins when to start a job automatically without manual intervention.

Common Mistakes

Writing the cron schedule incorrectly in the triggers block.

Jenkins will not trigger the job at the expected times or may fail to parse the schedule.

Use valid cron syntax and test schedules with online cron validators before adding them.

Forgetting to update the Jenkins job after changing the Jenkinsfile triggers.

Jenkins will continue using the old triggers and not the new ones.

Always run the update command or reload the job configuration after editing the Jenkinsfile.

Using both cron and pollSCM triggers without understanding their differences.

This can cause unexpected multiple job runs or missed triggers.

Choose the trigger that fits your use case or configure them carefully to avoid overlap.

Summary

The triggers directive in Jenkinsfile automates job start based on schedules or events.

Use cron to schedule jobs at specific times and pollSCM to trigger on source code changes.

Always update the Jenkins job configuration after changing triggers to apply them.

Practice

1. What is the main purpose of the triggers directive in a Jenkins pipeline?

easy

A. To configure the user permissions

B. To define the steps of the build process

C. To start jobs automatically based on time or events

D. To specify the environment variables

Solution

1. Step 1: Understand the role of triggers

   The triggers directive is used to start Jenkins jobs automatically without manual intervention.

2. Step 2: Compare with other pipeline directives

   Other directives like steps define build actions, environment sets variables, and permissions control access, not job start timing.

3. Final Answer:

   To start jobs automatically based on time or events -> Option C

4. Quick Check:

   Triggers = automatic job start [OK]

Hint: Triggers start jobs automatically by time or events [OK]

Common Mistakes:

• Confusing triggers with build steps
• Thinking triggers set environment variables
• Assuming triggers control user permissions

2. Which of the following is the correct syntax to trigger a Jenkins pipeline every day at midnight using the triggers directive?

easy

A. triggers { cron('0 0 * * *') }

B. triggers { cron('60 24 * * *') }

C. triggers { pollSCM('0 0 * * *') }

D. triggers { cron('0 0 0 * *') }

Solution

1. Step 1: Understand cron syntax in Jenkins

   Jenkins cron uses five fields: minute hour day month weekday. '0 0 * * *' means midnight every day.

2. Step 2: Identify correct trigger usage

   The triggers directive uses cron('schedule') to schedule jobs. pollSCM is for source control polling, not time-based triggers.

3. Final Answer:

   triggers { cron('0 0 * * *') } -> Option A

4. Quick Check:

   Midnight cron = '0 0 * * *' [OK]

Hint: Use cron('0 0 * * *') for daily midnight trigger [OK]

Common Mistakes:

• Using invalid cron times like '60 24'
• Confusing pollSCM with cron
• Misordering cron fields

3. Given this Jenkins pipeline snippet, what will trigger the job?

triggers {
  upstream(upstreamProjects: 'BuildApp', threshold: hudson.model.Result.SUCCESS)
}

medium

A. The job triggers manually only

B. The job triggers every minute

C. The job triggers when code is pushed to SCM

D. The job triggers when the 'BuildApp' job completes successfully

Solution

1. Step 1: Understand the upstream trigger

   The upstream trigger starts this job when the specified upstream job finishes with the given result.

2. Step 2: Analyze the parameters

   upstreamProjects: 'BuildApp' means the job named 'BuildApp' triggers this job. threshold SUCCESS means only on successful completion.

3. Final Answer:

   The job triggers when the 'BuildApp' job completes successfully -> Option D

4. Quick Check:

   Upstream job success triggers downstream [OK]

Hint: Upstream triggers run after specified job success [OK]

Common Mistakes:

• Thinking it triggers every minute
• Confusing upstream with SCM polling
• Assuming manual trigger only

4. Identify the error in this Jenkins pipeline trigger configuration:

triggers {
  cron('0 25 * * *')
}

medium

A. The hour field '25' is invalid in cron syntax

B. The cron syntax is correct and will run at 25 minutes past midnight

C. The cron directive should be inside a steps block

D. The cron string must have six fields, not five

Solution

1. Step 1: Check cron field ranges

   Cron fields are minute (0-59), hour (0-23), day, month, weekday. '25' in hour field is invalid.

2. Step 2: Validate placement and field count

   Cron is correctly placed in triggers and uses five fields, which is standard in Jenkins.

3. Final Answer:

   The hour field '25' is invalid in cron syntax -> Option A

4. Quick Check:

   Hour must be 0-23 in cron [OK]

Hint: Hour in cron must be 0-23, not 25 [OK]

Common Mistakes:

• Assuming cron has six fields
• Placing cron inside steps block
• Thinking 25 means 25 minutes

5. You want a Jenkins job to run every 15 minutes but only if there are changes in the source code repository. Which triggers directive setup achieves this?

hard

A. triggers { cron('*/15 * * * *') }

B. triggers { pollSCM('H/15 * * * *') }

C. triggers { upstream(upstreamProjects: 'RepoUpdate', threshold: hudson.model.Result.SUCCESS) }

D. triggers { pollSCM('0 0 * * *') }

Solution

1. Step 1: Understand pollSCM usage

   pollSCM triggers the job every specified interval but only if SCM changes are detected.

2. Step 2: Analyze the cron expressions

   'H/15 * * * *' means every 15 minutes with hashing for load balancing. cron triggers regardless of SCM changes.

3. Final Answer:

   triggers { pollSCM('H/15 * * * *') } -> Option B

4. Quick Check:

   pollSCM runs on changes every 15 minutes [OK]

Hint: Use pollSCM with 'H/15 * * * *' for change-based 15-min trigger [OK]

Common Mistakes:

• Using cron which triggers regardless of changes
• Confusing upstream trigger with SCM polling
• Setting pollSCM to wrong cron expression