Keeping pipelines fast in Jenkins - Time & Space Complexity
We want to understand how the time it takes to run a Jenkins pipeline grows as we add more steps or jobs.
How does adding more tasks affect the total pipeline time?
Analyze the time complexity of the following Jenkins pipeline snippet.
pipeline {
agent any
stages {
stage('Build') {
steps {
script {
for (int i = 0; i < jobs.size(); i++) {
build job: jobs[i]
}
}
}
}
}
}
This pipeline runs a list of jobs one after another inside a loop.
Look for repeated actions that take time.
- Primary operation: Running each job with
build job: jobs[i]. - How many times: Once for each job in the
jobslist.
As the number of jobs grows, the total time grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 job runs |
| 100 | 100 job runs |
| 1000 | 1000 job runs |
Pattern observation: The total time grows directly with the number of jobs.
Time Complexity: O(n)
This means if you double the number of jobs, the pipeline takes about twice as long.
[X] Wrong: "Running jobs in a loop is always fast because Jenkins handles them quickly."
[OK] Correct: Each job runs one after another, so more jobs mean more total time, not less.
Understanding how pipeline time grows helps you design faster builds and shows you can think about efficiency in real projects.
What if we changed the loop to run jobs in parallel? How would the time complexity change?
Practice
Solution
Step 1: Understand pipeline speed impact
Fast pipelines reduce wait time for developers and speed up delivery.Step 2: Identify the benefit of fast pipelines
Faster pipelines improve team efficiency and allow quicker feedback.Final Answer:
To deliver code quickly and improve team efficiency -> Option BQuick Check:
Fast pipelines = faster delivery [OK]
- Thinking more steps make pipelines faster
- Believing longer logs improve speed
- Assuming more resource use equals speed
Solution
Step 1: Recall Jenkins timeout syntax
The correct syntax uses named parameters: time and unit.Step 2: Match correct syntax
timeout(time: 10, unit: 'MINUTES') { /* steps */ } uses timeout(time: 10, unit: 'MINUTES') which is valid Groovy syntax.Final Answer:
timeout(time: 10, unit: 'MINUTES') { /* steps */ } -> Option AQuick Check:
timeout(time: 10, unit: 'MINUTES') = correct syntax [OK]
- Using timeout(10 minutes) without quotes
- Missing unit parameter
- Using equal signs instead of colons
pipeline {
agent any
stages {
stage('Parallel') {
parallel {
stage('A') { steps { echo 'Running A' } }
stage('B') { steps { echo 'Running B' } }
}
}
}
}Solution
Step 1: Analyze parallel block syntax in Jenkins Declarative Pipeline
The parallel block can contain nested stages inside it in Declarative Pipeline syntax.Step 2: Identify the behavior
Stages A and B inside parallel run concurrently, so both run at the same time.Final Answer:
Runs stages A and B at the same time -> Option AQuick Check:
parallel runs stages concurrently [OK]
- Thinking stages can not be nested inside parallel
- Assuming parallel runs stages sequentially
- Believing the syntax is invalid
stage('Build') {
steps {
sh 'sleep 60'
}
}Solution
Step 1: Identify slow step
The 'sleep 60' command pauses the pipeline for 60 seconds, slowing it down.Step 2: Fix by removing or reducing sleep
Removing or reducing sleep will speed up the pipeline.Final Answer:
Remove the sleep command or reduce its duration -> Option DQuick Check:
Removing delays = faster pipeline [OK]
- Adding more sleep commands
- Increasing timeout instead of fixing delay
- Thinking sleep is non-blocking
Solution
Step 1: Understand the condition to skip tests
Tests should be skipped if commit message contains '[skip tests]'.Step 2: Match correct logic and commands
if (env.GIT_COMMIT_MESSAGE.contains('[skip tests]')) { echo 'Skipping tests'; } else { sh 'run-tests.sh' } checks for '[skip tests]' and skips tests by echoing message; else runs tests.Final Answer:
if (env.GIT_COMMIT_MESSAGE.contains('[skip tests]')) { echo 'Skipping tests'; } else { sh 'run-tests.sh' } -> Option CQuick Check:
Correct condition and action = if (env.GIT_COMMIT_MESSAGE.contains('[skip tests]')) { echo 'Skipping tests'; } else { sh 'run-tests.sh' } [OK]
- Using equality instead of contains
- Reversing the if-else logic
- Missing brackets in string match
Ready to prove it?
Pass the test and this pattern moves unknown
