Poll SCM configuration in Jenkins - Commands & Configuration

Introduction

Sometimes you want Jenkins to check your code repository regularly to see if there are any changes. Poll SCM configuration lets Jenkins look for updates on a schedule and start a build only when there is new code. This saves time and resources by not building when nothing changed.

When you want Jenkins to automatically build your project only if new code is pushed to the repository.

When you do not have webhooks set up to notify Jenkins about code changes.

When you want to reduce unnecessary builds and save server resources.

When your team commits code at irregular times and you want Jenkins to check periodically.

When you want a simple way to trigger builds without complex event setups.

Commands

This command downloads the current configuration of the Jenkins job named 'example-job' to a file called job-config.xml so you can edit it.

Terminal

jenkins-cli get-job example-job > job-config.xml

Expected Output

<?xml version="1.0" encoding="UTF-8"?>

<project>

  ...

</project>

This command adds the Poll SCM trigger to the job configuration XML, setting Jenkins to check the source code every 5 minutes.

Terminal

sed -i '/<triggers>/a\    <hudson.triggers.SCMTrigger>\n      <spec>H/5 * * * *</spec>\n    </hudson.triggers.SCMTrigger>' job-config.xml

Expected Output

No output (command runs silently)

This command uploads the modified job configuration back to Jenkins, applying the Poll SCM schedule to the job.

Terminal

jenkins-cli update-job example-job < job-config.xml

Expected Output

No output (command runs silently)

This command verifies that the Poll SCM trigger was added by showing the triggers section of the job configuration.

Terminal

jenkins-cli get-job example-job | grep -A 3 '<triggers>'

Expected Output

  <triggers>

    <hudson.triggers.SCMTrigger>

      <spec>H/5 * * * *</spec>

    </hudson.triggers.SCMTrigger>

Key Concept

If you remember nothing else from this pattern, remember: Poll SCM lets Jenkins check your code repository on a schedule and build only when there are changes.

Common Mistakes

Setting the Poll SCM schedule to an invalid cron syntax.

Jenkins will reject the configuration or ignore the trigger, so builds won't start as expected.

Use valid cron syntax like 'H/5 * * * *' to schedule polling every 5 minutes.

Forgetting to update the job configuration after editing the XML file.

Changes won't take effect, so Jenkins will not poll the SCM.

Always upload the modified job configuration back to Jenkins using the update-job command.

Using Poll SCM and webhooks together without understanding their interaction.

This can cause duplicate builds or unexpected triggers.

Choose either Poll SCM or webhooks to trigger builds to avoid conflicts.

Summary

Use Jenkins CLI to download the job configuration XML file.

Add the Poll SCM trigger with a valid cron schedule inside the triggers section.

Upload the updated configuration back to Jenkins to apply the changes.

Verify the Poll SCM trigger is set by inspecting the job configuration.

Practice

1.

What is the main purpose of the Poll SCM option in Jenkins?

easy

A. To send notifications when a build fails

B. To manually start a build whenever you want

C. To deploy the application automatically after every build

D. To regularly check the source code repository for changes and trigger builds if changes are found

Solution

1. Step 1: Understand Poll SCM function

   Poll SCM is designed to check the source code repository at regular intervals for any new changes.

2. Step 2: Identify the trigger action

   When changes are detected, Jenkins triggers a build automatically.

3. Final Answer:

   To regularly check the source code repository for changes and trigger builds if changes are found -> Option D

4. Quick Check:

   Poll SCM triggers builds on repo changes [OK]

Hint: Poll SCM triggers builds only when repo changes appear [OK]

Common Mistakes:

• Confusing Poll SCM with manual build triggers
• Thinking Poll SCM deploys code automatically
• Assuming Poll SCM sends notifications

2.

Which of the following is the correct way to set a Poll SCM schedule to check every 15 minutes in Jenkins?

easy

A. */15 * * * *

B. 0 */15 * * *

C. 0 15 * * *

D. 15 * * * *

Solution

1. Step 1: Understand cron syntax for every 15 minutes

   The syntax "*/15 * * * *" means every 15 minutes at minute 0, 15, 30, 45.

2. Step 2: Compare options

   0 */15 * * * "0 */15 * * *" polls at minute 0 every 15 hours (e.g., 00:00, 15:00); A is standard cron for every 15 minutes; Options C and D specify fixed times, not every 15 minutes.

3. Final Answer:

   */15 * * * * -> Option A

4. Quick Check:

   */15 means every 15 minutes [OK]

Hint: Use */15 in first field for every 15 minutes polling [OK]

Common Mistakes:

• Using fixed minute values instead of intervals
• Putting interval */15 in the hour field instead of minute field
• Setting wrong fields for minutes

3.

Given the Poll SCM schedule H/10 * * * *, what will Jenkins do?

medium

A. Poll the SCM every 10 minutes starting exactly at minute 0

B. Poll the SCM only once every hour at minute 10

C. Poll the SCM every 10 minutes starting at a random minute each hour

D. Poll the SCM every 10 seconds

Solution

1. Step 1: Understand Jenkins H/ syntax

   The 'H' means Jenkins picks a random minute to spread load; 'H/10' means every 10 minutes starting from that random minute.

2. Step 2: Interpret the schedule

   Jenkins polls SCM every 10 minutes but start time varies per job to avoid all jobs polling simultaneously.

3. Final Answer:

   Poll the SCM every 10 minutes starting at a random minute each hour -> Option C

4. Quick Check:

   H/10 means every 10 minutes from random start [OK]

Hint: H/10 means every 10 minutes from random start minute [OK]

Common Mistakes:

• Thinking H/10 starts exactly at minute 0
• Confusing seconds with minutes
• Assuming polling happens only once per hour

4.

You set Poll SCM with schedule H/5 * * * * but Jenkins never triggers builds even when code changes. What is the most likely cause?

medium

A. The Poll SCM schedule syntax is invalid

B. The repository URL is incorrect or unreachable

C. Polling triggers builds even without changes

D. Jenkins does not support Poll SCM for Git repositories

Solution

1. Step 1: Check Poll SCM schedule validity

   Schedule 'H/5 * * * *' is valid and means poll every 5 minutes.

2. Step 2: Identify why builds don't trigger

   If no builds trigger despite changes, likely Jenkins cannot access the repo to detect changes.

3. Final Answer:

   The repository URL is incorrect or unreachable -> Option B

4. Quick Check:

   Unreachable repo stops polling builds [OK]

Hint: Check repo URL if Poll SCM triggers no builds [OK]

Common Mistakes:

• Assuming Poll SCM triggers builds without changes
• Blaming schedule syntax when it's correct
• Thinking Jenkins can't poll Git repos

5.

You want Jenkins to poll your Git repository only during office hours (9 AM to 5 PM) every 30 minutes. Which Poll SCM schedule should you use?

hard

A. H/30 9-16 * * *

B. H/30 9-17 * * *

C. H/30 9-18 * * *

D. H/30 8-17 * * *

Solution

1. Step 1: Understand hour range in cron

   Hours are 0-23; '9-16' covers 9:00 to 16:59 (9 AM to 4:59 PM), matching office hours 9 AM to 5 PM excluding the 5 PM hour.

2. Step 2: Match office hours 9 AM to 5 PM

   9-16 includes up to 4:59 PM; 9-17 includes the full 5 PM hour (up to 5:59 PM).

3. Step 3: Confirm polling every 30 minutes

   H/30 means every 30 minutes starting at a hashed minute.

4. Final Answer:

   H/30 9-16 * * * -> Option A

5. Quick Check:

   9-16 hours covers 9 AM to 4:59 PM [OK]

Hint: Use hour range 9-16 for 9 AM to 5 PM polling excluding 5 PM hour [OK]

Common Mistakes:

• Using 9-17 which includes the 5 PM hour
• Confusing hour ranges in cron syntax
• Forgetting H/30 means every 30 minutes