Triggers directive in Jenkins - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the effect of this Jenkins pipeline triggers directive?

Consider this Jenkins pipeline snippet:

triggers {
  cron('H 4/4 * * 1-5')
}

What does this trigger configuration do?

Jenkins

triggers {
  cron('H 4/4 * * 1-5')
}

A Schedules the job to run every hour at 4 minutes past, Monday to Friday.

B Schedules the job to run every 4 hours on weekdays.

C Schedules the job to run at 4 AM every day from Monday to Friday.

D Schedules the job to run at 4 AM on the first five days of every month.

💡 Hint

Remember that 'H' is a hash-based random minute, and '4/4' means every 4 hours starting at hour 4.

The cron expression 'H 4/4 * * 1-5' means the job runs at a hashed minute (H), every 4 hours starting at hour 4, on weekdays (1-5). So it runs every 4 hours on Monday to Friday.

🧠 Conceptual

intermediate

Which Jenkins trigger directive starts a build when a GitHub push event occurs?

You want your Jenkins pipeline to start automatically when someone pushes code to GitHub. Which trigger directive should you use?

A githubPush()

B pollSCM { cron('H/5 * * * *') }

C upstream('other-job')

D cron('H 0 * * *')

💡 Hint

Think about triggers that respond to external events rather than time schedules.

The 'githubPush()' trigger listens for GitHub push events and starts the build immediately when code is pushed.

❓ Troubleshoot

advanced

Why does this Jenkins pipeline not trigger as expected?

Given this Jenkins pipeline snippet:

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

The job does not start automatically even though the repository has new commits. What is the most likely cause?

Jenkins

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

A pollSCM only schedules polling; it does not guarantee immediate builds on new commits.

B The pollSCM trigger requires a webhook to be configured in the repository.

C The Jenkins user does not have permission to access the repository.

D The cron syntax 'H/15 * * * *' is invalid and causes the trigger to fail.

💡 Hint

Consider how pollSCM works compared to event-driven triggers.

pollSCM schedules Jenkins to check the repository every 15 minutes. It does not trigger builds immediately on commit; if polling misses changes or is delayed, builds may not start instantly.

🔀 Workflow

advanced

How to configure a Jenkins pipeline to trigger after another job completes successfully?

You want your Jenkins pipeline to start only after another job named 'Build-App' finishes successfully. Which triggers directive achieves this?

A triggers { cron('H 2 * * *') }

B triggers { pollSCM('H/10 * * * *') }

C triggers { githubPush() }

D triggers { upstream('Build-App', 'SUCCESS') }

💡 Hint

Look for a trigger that listens to other job completions.

The 'upstream' trigger listens for the completion of another job. Specifying 'SUCCESS' means it triggers only if the upstream job finishes successfully.

✅ Best Practice

expert

What is the best practice for using the triggers directive to avoid unnecessary builds?

Which approach best reduces unnecessary Jenkins builds when using triggers in pipelines?

A Disable all triggers and start builds manually to avoid any unnecessary runs.

B Use cron triggers only and avoid event-based triggers to keep builds predictable.

C Use event-driven triggers like githubPush() combined with minimal polling to reduce load.

D Use pollSCM with a very frequent schedule like every minute to catch all changes quickly.

💡 Hint

Think about balancing responsiveness and resource use.

Event-driven triggers like githubPush() start builds immediately on changes, reducing unnecessary polling. Minimal polling can catch missed events, balancing load and responsiveness.

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