Poll SCM configuration in Jenkins - Time & Space Complexity
We want to understand how the time taken by Jenkins changes when it checks for source code updates using Poll SCM.
Specifically, how does the checking time grow as the number of files or changes increases?
Analyze the time complexity of the following Jenkins Poll SCM configuration snippet.
pipeline {
agent any
triggers {
pollSCM('H/5 * * * *')
}
stages {
stage('Build') {
steps {
echo 'Building...'
}
}
}
}
This code sets Jenkins to check the source code repository every 5 minutes for any changes before running the build.
Look at what Jenkins does repeatedly when polling SCM.
- Primary operation: Checking each file or commit in the source repository for changes.
- How many times: Every 5 minutes, Jenkins scans all relevant files or commits since the last check.
As the number of files or commits grows, Jenkins spends more time checking each one.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 files/commits | 10 checks |
| 100 files/commits | 100 checks |
| 1000 files/commits | 1000 checks |
Pattern observation: The checking time grows directly with the number of files or commits to scan.
Time Complexity: O(n)
This means the time Jenkins takes to poll grows in a straight line with the number of files or commits it checks.
[X] Wrong: "Polling SCM always takes the same time no matter how many files there are."
[OK] Correct: Jenkins must check each file or commit, so more files mean more work and longer polling time.
Understanding how Jenkins polling scales helps you explain build delays and plan efficient pipelines in real projects.
"What if Jenkins used webhooks instead of polling? How would the time complexity change?"
Practice
What is the main purpose of the Poll SCM option in Jenkins?
Solution
Step 1: Understand Poll SCM function
Poll SCM is designed to check the source code repository at regular intervals for any new changes.Step 2: Identify the trigger action
When changes are detected, Jenkins triggers a build automatically.Final Answer:
To regularly check the source code repository for changes and trigger builds if changes are found -> Option DQuick Check:
Poll SCM triggers builds on repo changes [OK]
- Confusing Poll SCM with manual build triggers
- Thinking Poll SCM deploys code automatically
- Assuming Poll SCM sends notifications
Which of the following is the correct way to set a Poll SCM schedule to check every 15 minutes in Jenkins?
Solution
Step 1: Understand cron syntax for every 15 minutes
The syntax "*/15 * * * *" means every 15 minutes at minute 0, 15, 30, 45.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.Final Answer:
*/15 * * * * -> Option AQuick Check:
*/15 means every 15 minutes [OK]
- Using fixed minute values instead of intervals
- Putting interval */15 in the hour field instead of minute field
- Setting wrong fields for minutes
Given the Poll SCM schedule H/10 * * * *, what will Jenkins do?
Solution
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.Step 2: Interpret the schedule
Jenkins polls SCM every 10 minutes but start time varies per job to avoid all jobs polling simultaneously.Final Answer:
Poll the SCM every 10 minutes starting at a random minute each hour -> Option CQuick Check:
H/10 means every 10 minutes from random start [OK]
- Thinking H/10 starts exactly at minute 0
- Confusing seconds with minutes
- Assuming polling happens only once per hour
You set Poll SCM with schedule H/5 * * * * but Jenkins never triggers builds even when code changes. What is the most likely cause?
Solution
Step 1: Check Poll SCM schedule validity
Schedule 'H/5 * * * *' is valid and means poll every 5 minutes.Step 2: Identify why builds don't trigger
If no builds trigger despite changes, likely Jenkins cannot access the repo to detect changes.Final Answer:
The repository URL is incorrect or unreachable -> Option BQuick Check:
Unreachable repo stops polling builds [OK]
- Assuming Poll SCM triggers builds without changes
- Blaming schedule syntax when it's correct
- Thinking Jenkins can't poll Git repos
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?
Solution
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.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).Step 3: Confirm polling every 30 minutes
H/30 means every 30 minutes starting at a hashed minute.Final Answer:
H/30 9-16 * * * -> Option AQuick Check:
9-16 hours covers 9 AM to 4:59 PM [OK]
- Using 9-17 which includes the 5 PM hour
- Confusing hour ranges in cron syntax
- Forgetting H/30 means every 30 minutes
Ready to prove it?
Pass the test and this pattern moves unknown
