📖 Scenario: You are a DevOps engineer working with Jenkins to automate software builds and deployments. You want to understand why scripted pipelines in Jenkins provide more flexibility compared to declarative pipelines.
🎯 Goal: Build a simple Jenkins scripted pipeline that demonstrates flexibility by using variables, conditional logic, and loops.
📋 What You'll Learn
Create a variable to hold a list of build stages
Add a configuration variable to control whether to run tests
Use a loop to iterate over the stages and run them
Print the stages that were run
💡 Why This Matters
🌍 Real World
In real projects, scripted pipelines help automate complex workflows that need decisions and loops, like running tests only on certain branches or deploying to different environments.
💼 Career
Understanding scripted pipelines is important for DevOps roles because it allows customizing Jenkins automation beyond simple linear steps, making your automation smarter and more adaptable.
Progress0 / 4 steps
1
Create a list of build stages
Create a variable called stages and assign it the list ["Build", "Test", "Deploy"].
Jenkins
Hint
Use square brackets to create a list and assign it to stages.
2
Add a configuration variable to control testing
Create a variable called runTests and set it to true to control whether the Test stage runs.
Jenkins
Hint
Use true (lowercase) to set the boolean variable runTests.
3
Use a loop and conditional to run stages
Use a for loop with variable stage to iterate over stages. Inside the loop, use an if statement to skip the Test stage if runTests is false. Print "Running stage" for each stage run.
Jenkins
Hint
Use continue to skip the Test stage when runTests is false.
4
Print the stages that were run
Add a print statement after the loop to display "Stages completed: " followed by the list of stages that were run. Use a list called completedStages to collect stages inside the loop.
Jenkins
Hint
Use add() to add stages to the list and print it after the loop.
Practice
(1/5)
1. Why do scripted pipelines in Jenkins offer more flexibility compared to declarative pipelines?
easy
A. Because they only support predefined stages without customization.
B. Because they have a simpler syntax with fewer features.
C. Because they allow using loops, conditions, and custom error handling.
D. Because they automatically generate pipeline code without user input.
Solution
Step 1: Understand scripted pipeline features
Scripted pipelines allow writing code with loops, conditions, and error handling, giving more control.
Step 2: Compare with declarative pipelines
Declarative pipelines have a simpler, fixed structure and less flexibility for complex logic.
Final Answer:
Because they allow using loops, conditions, and custom error handling. -> Option C
Quick Check:
Scripted pipelines = flexible code control [OK]
Hint: Look for options mentioning loops and conditions for flexibility [OK]
Common Mistakes:
Confusing simplicity with flexibility
Thinking declarative pipelines allow all custom code
Assuming scripted pipelines auto-generate code
2. Which of the following is the correct syntax to start a scripted pipeline block in Jenkins?
easy
A. node {
B. stage {
C. pipeline {
D. scripted {
Solution
Step 1: Identify scripted pipeline block syntax
Scripted pipelines start with node { to define the workspace and steps.
Step 2: Eliminate other options
pipeline { is for declarative pipelines; stage { defines a stage; scripted { is invalid syntax.
Final Answer:
node { -> Option A
Quick Check:
Scripted pipeline starts with node block [OK]
Hint: Scripted pipelines start with 'node {' block [OK]
Common Mistakes:
Using 'pipeline {' which is declarative syntax
Confusing 'stage {' as pipeline start
Assuming 'scripted {' is valid syntax
3. What will be the output of this scripted pipeline snippet?
node {
for (int i = 1; i <= 3; i++) {
echo "Count: ${i}"
}
}
medium
A. Count: 1\nCount: 2\nCount: 3
B. Count: 0\nCount: 1\nCount: 2
C. Syntax error due to for loop
D. No output because echo is invalid
Solution
Step 1: Analyze the for loop range
The loop runs from i=1 to i=3 inclusive, so it iterates 3 times.
Step 2: Check the echo output each iteration
Each iteration prints "Count: " followed by the current i value, producing lines for 1, 2, and 3.
Final Answer:
Count: 1\nCount: 2\nCount: 3 -> Option A
Quick Check:
Loop 1 to 3 prints counts 1,2,3 [OK]
Hint: Check loop start and end values carefully [OK]
Common Mistakes:
Starting loop at 0 instead of 1
Thinking echo is invalid in scripted pipeline
Assuming syntax error in for loop
4. Identify the error in this scripted pipeline snippet:
node {
if (env.BRANCH_NAME == 'main')
echo 'Deploying to production'
else
echo 'Deploying to staging'
}
medium
A. node block cannot contain if statements
B. Missing curly braces {} around if and else blocks
C. echo command cannot be used inside if
D. Incorrect use of env variable syntax
Solution
Step 1: Check if-else syntax in scripted pipeline
In scripted pipelines, if and else blocks must use curly braces {} when spanning multiple lines or statements.
Step 2: Identify missing braces
The snippet lacks braces around the echo statements, which can cause syntax errors or unexpected behavior.
Final Answer:
Missing curly braces {} around if and else blocks -> Option B
Quick Check:
If-else blocks need braces in scripted pipelines [OK]
Hint: Always use braces {} for if-else blocks in scripted pipelines [OK]
Common Mistakes:
Assuming env.BRANCH_NAME syntax is wrong
Thinking echo can't be inside if
Believing node block forbids if statements
5. You want to retry a build step up to 3 times if it fails, using a scripted pipeline. Which snippet correctly implements this retry logic?
hard
A. node {
for (int i=0; i<3; i++) {
sh 'run-build.sh'
}
}
B. node {
while (true) {
sh 'run-build.sh'
}
}
C. node {
try {
sh 'run-build.sh'
} catch (err) {
retry(3)
}
}
D. node {
retry(3) {
sh 'run-build.sh'
}
}
Solution
Step 1: Understand Jenkins retry step
The retry(n) { ... } block retries the enclosed steps up to n times on failure automatically.
Step 2: Evaluate each option
node {
retry(3) {
sh 'run-build.sh'
}
} correctly uses retry(3) around the build command. node {
for (int i=0; i<3; i++) {
sh 'run-build.sh'
}
} runs the command 3 times without retry on failure. node {
try {
sh 'run-build.sh'
} catch (err) {
retry(3)
}
} misuses retry inside catch. node {
while (true) {
sh 'run-build.sh'
}
} loops infinitely.
Final Answer:
node {
retry(3) {
sh 'run-build.sh'
}
} -> Option D
Quick Check:
Use retry(n) block for automatic retries [OK]
Hint: Use retry(n) block to retry steps automatically [OK]
Common Mistakes:
Using loops instead of retry block
Placing retry inside catch block incorrectly
Creating infinite loops without exit
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.