Poll SCM configuration in Jenkins - Step-by-Step Execution

Process Flow - Poll SCM configuration

Start Jenkins Job

↓

Check Poll SCM Schedule

↓

Is current time matching schedule?

No→Wait until next check

Yes↓

Poll SCM for changes

↓

Are there changes?

No→Do not build, wait for next poll

Yes↓

Trigger Build

↓

End Job Cycle

Jenkins checks the SCM at scheduled times; if changes are found, it triggers a build, otherwise waits for the next poll.

Execution Sample

Jenkins

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

// Jenkins polls SCM every 15 minutes

This Jenkins pipeline snippet configures polling SCM every 15 minutes to detect changes and trigger builds.

Process Table

Step	Time	Poll SCM Triggered?	SCM Changes Detected?	Action Taken
1	00:00	Yes	No	No build triggered, wait for next poll
2	00:15	Yes	Yes	Build triggered
3	00:30	Yes	No	No build triggered, wait for next poll
4	00:45	Yes	Yes	Build triggered
5	01:00	Yes	No	No build triggered, wait for next poll
6	01:15	Yes	No	No build triggered, wait for next poll

💡 Polling continues indefinitely at scheduled intervals; builds only triggered when SCM changes are detected.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6
Time	00:00	00:15	00:30	00:45	01:00	01:15	01:30
Poll SCM Triggered	Yes	Yes	Yes	Yes	Yes	Yes	Yes
SCM Changes Detected	No	Yes	No	Yes	No	No	Yes
Build Triggered	No	Yes	No	Yes	No	No	Yes

Key Moments - 3 Insights

Why doesn't Jenkins trigger a build every time it polls SCM?

Jenkins triggers a build only if SCM changes are detected during the poll, as shown in execution_table rows 1 and 3 where polling occurs but no changes are found, so no build is triggered.

What does the schedule 'H/15 * * * *' mean in Poll SCM?

It means Jenkins polls SCM every 15 minutes at a hashed time to distribute load, as reflected in the execution_table times (00:00, 00:15, 00:30, etc.).

Does Jenkins build immediately after a commit to SCM?

No, Jenkins builds only at the next scheduled poll time after detecting changes, not instantly on commit, as seen in the delay between SCM changes and build triggers in the table.

Visual Quiz - 3 Questions

Look at the execution table, at which time is a build triggered after SCM changes are detected?

A 00:15

B 00:30

C 01:00

D 01:15

💡 Hint

Check the 'Build Triggered' column for 'Yes' and match with 'SCM Changes Detected' at the same step.

At which step does Jenkins poll SCM but no changes are detected?

A Step 2

B Step 3

C Step 4

D Step 6

💡 Hint

Look at 'SCM Changes Detected?' column for 'No' while 'Poll SCM Triggered?' is 'Yes'.

If the polling schedule changed to every 30 minutes, how would the execution table change?

A SCM changes would be detected more frequently

B Builds would trigger twice as often

C Polling steps would occur every 30 minutes instead of 15

D Builds would trigger immediately on commit

💡 Hint

Polling frequency controls how often Jenkins checks SCM, not how often changes occur or builds trigger.

Concept Snapshot

Poll SCM in Jenkins:
- Configure with cron-like syntax (e.g., 'H/15 * * * *')
- Jenkins checks SCM at scheduled times
- If changes detected, triggers build
- If no changes, waits for next poll
- Polling spreads load using 'H' (hash) for timing

Full Transcript

Poll SCM configuration in Jenkins means setting a schedule for Jenkins to check the source code repository for changes. Jenkins uses a cron-like syntax to decide when to poll. At each scheduled time, Jenkins checks if there are any new commits or changes in the SCM. If changes are found, Jenkins triggers a build to update the project. If no changes are found, Jenkins waits until the next scheduled poll. This process repeats indefinitely, ensuring builds only happen when needed, saving resources and time.

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