currentBuild variables in Jenkins - Time & Space Complexity
We want to understand how using currentBuild variables affects the time it takes for a Jenkins pipeline to run.
Specifically, how does accessing or updating these variables change the work Jenkins does as the pipeline grows?
Analyze the time complexity of the following Jenkins pipeline snippet.
pipeline {
agent any
stages {
stage('Example') {
steps {
script {
for (int i = 0; i < n; i++) {
currentBuild.description = "Build step " + i
}
}
}
}
}
}
This code updates the currentBuild.description variable inside a loop that runs n times.
Look for repeated actions in the code.
- Primary operation: Updating
currentBuild.descriptioninside the loop. - How many times: The loop runs
ntimes, so the update happensntimes.
As n grows, the number of updates grows the same way.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 updates to currentBuild.description |
| 100 | 100 updates to currentBuild.description |
| 1000 | 1000 updates to currentBuild.description |
Pattern observation: The work grows directly with the number of loop iterations.
Time Complexity: O(n)
This means the time to update currentBuild.description grows linearly as the number of updates increases.
[X] Wrong: "Updating currentBuild variables inside a loop is instant and does not add time."
[OK] Correct: Each update triggers Jenkins to process and save the change, so doing it many times adds up and takes longer.
Understanding how repeated updates to build variables affect pipeline time helps you write efficient Jenkins pipelines and shows you think about scaling your automation.
What if we updated currentBuild.description only once after the loop instead of inside it? How would the time complexity change?