When to use scripted over declarative in Jenkins - Time & Space Complexity
We want to understand how the choice between scripted and declarative Jenkins pipelines affects the time it takes to run jobs as they grow in size and complexity.
How does the pipeline style impact the work Jenkins does as we add more steps or logic?
Analyze the time complexity of this scripted pipeline snippet.
node {
stage('Build') {
for (int i = 0; i < stepsCount; i++) {
echo "Running build step ${i}"
// simulate build step
}
}
stage('Test') {
echo 'Running tests'
}
}
This scripted pipeline runs a loop of build steps followed by a test stage.
Look for loops or repeated actions that affect execution time.
- Primary operation: The for-loop running build steps repeatedly.
- How many times: The loop runs
stepsCounttimes, which can vary.
As stepsCount grows, the number of build steps increases linearly.
| Input Size (stepsCount) | Approx. Operations |
|---|---|
| 10 | 10 build steps + 1 test stage |
| 100 | 100 build steps + 1 test stage |
| 1000 | 1000 build steps + 1 test stage |
Pattern observation: The total work grows directly with the number of build steps.
Time Complexity: O(n)
This means the time to run the pipeline grows in a straight line as you add more build steps.
[X] Wrong: "Using scripted pipelines always makes execution slower than declarative ones."
[OK] Correct: The execution time depends on the number of steps and logic, not just the pipeline style. Scripted pipelines can be just as fast if they avoid unnecessary loops or complex logic.
Understanding how pipeline style affects execution helps you explain trade-offs clearly and shows you can think about scaling Jenkins jobs efficiently.
What if we replaced the for-loop with parallel steps? How would the time complexity change?