📖 Scenario: You are setting up a Jenkins pipeline to automate your software build process. Jenkins pipelines use stages to organize tasks like building, testing, and deploying your code.
🎯 Goal: Build a simple Jenkins pipeline script with three stages: Build, Test, and Deploy. Each stage will have a simple echo command to show its execution.
📋 What You'll Learn
Create a Jenkins pipeline script using the pipeline block
Add a stages block inside the pipeline
Define three stages named Build, Test, and Deploy
Each stage should have a steps block with an echo command describing the stage
💡 Why This Matters
🌍 Real World
Jenkins pipelines automate software builds, tests, and deployments in many companies.
💼 Career
Understanding stage blocks is essential for DevOps engineers to create clear and maintainable CI/CD pipelines.
Progress0 / 4 steps
1
Create the pipeline and stages blocks
Write a Jenkins pipeline script starting with pipeline { and inside it add an empty stages { } block.
Jenkins
Hint
Start with pipeline { and add stages { } inside it.
2
Add the Build stage with echo step
Inside the stages block, add a stage named Build with a steps block that contains echo 'Building the project'.
Jenkins
Hint
Use stage('Build') { steps { echo 'Building the project' } } inside stages.
3
Add Test and Deploy stages with echo steps
Add two more stages inside stages: Test with echo 'Testing the project' and Deploy with echo 'Deploying the project'.
Jenkins
Hint
Add stage('Test') { steps { echo 'Testing the project' } } and stage('Deploy') { steps { echo 'Deploying the project' } } inside stages.
4
Print the complete pipeline script
Print the entire Jenkins pipeline script you created to verify the structure.
Jenkins
Hint
Use println to print a confirmation message.
Practice
(1/5)
1. What is the main purpose of a stage block in a Jenkins pipeline?
easy
A. To define environment variables for the pipeline
B. To divide the pipeline into named steps for better organization and tracking
C. To specify the agent where the pipeline runs
D. To declare global variables accessible in all stages
Solution
Step 1: Understand the role of stage in Jenkins
The stage block is used to split the pipeline into named sections, making it easier to follow and debug.
Step 2: Compare with other pipeline blocks
Other blocks like environment or agent serve different purposes, not organizing steps.
Final Answer:
To divide the pipeline into named steps for better organization and tracking -> Option B
Quick Check:
Stage block purpose = organization [OK]
Hint: Stages name steps to track progress clearly [OK]
Common Mistakes:
Confusing stage with environment block
Thinking stage sets agents
Assuming stage declares variables
2. Which of the following is the correct syntax for defining a stage named Build with a simple shell command in Jenkins declarative pipeline?
easy
A. stage('Build') { step { sh 'make' } }
B. stage: 'Build' { steps { sh 'make' } }
C. stage('Build') { steps { sh 'make' } }
D. stage('Build') steps { sh 'make' }
Solution
Step 1: Recall correct stage block syntax
The correct syntax uses stage('Name') { steps { ... } } with curly braces and plural steps.
Step 2: Identify syntax errors in other options
The other options contain these errors: singular step instead of plural steps, colon : instead of parentheses for the stage name, and missing opening brace before steps.
Final Answer:
stage('Build') { steps { sh 'make' } } -> Option C
The pipeline defines a single stage named 'Test' with a step that echoes 'Running tests'.
Step 2: Understand echo behavior in Jenkins
The echo command prints the given string to the console output during the stage execution.
Final Answer:
Running tests -> Option D
Quick Check:
Echo prints message = Running tests [OK]
Hint: Echo prints text inside steps block [OK]
Common Mistakes:
Assuming echo does not print
Thinking stage is skipped
Confusing syntax errors
4. Identify the error in this Jenkins pipeline stage block:
stage('Deploy') {
step {
sh 'deploy.sh'
}
}
medium
A. The block should use steps instead of step
B. The stage name must be lowercase
C. The sh command is invalid inside a stage
D. Missing agent declaration inside the stage
Solution
Step 1: Check the block keyword inside stage
The correct keyword to wrap commands inside a stage is steps (plural), not step.
Step 2: Verify other options
Stage names can be any case, sh is valid inside steps, and agent is optional if defined globally.
Final Answer:
The block should use steps instead of step -> Option A
Quick Check:
Use 'steps' block inside stage [OK]
Hint: Inside stage, use 'steps' plural for commands [OK]
Common Mistakes:
Using singular 'step' instead of 'steps'
Thinking stage name case matters
Assuming sh is invalid inside stage
5. You want to create a Jenkins pipeline with two stages: Build and Test. The Test stage should only run if the Build stage succeeds. Which structure correctly enforces this using stage blocks?
hard
A. pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { when { expression { currentBuild.result == null || currentBuild.result == 'SUCCESS' } } steps { sh 'make test' } } } }
B. pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { steps { sh 'make test' } } } }
C. pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { when { branch 'main' } steps { sh 'make test' } } } }
D. pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { steps { sh 'make test' } post { always { echo 'Test done' } } } } }
Solution
Step 1: Understand stage execution conditions
By default, stages run sequentially but may run even if previous stages fail. To run Test only if Build succeeds, use a when condition checking build result.
Step 2: Analyze options for conditional execution
pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { when { expression { currentBuild.result == null || currentBuild.result == 'SUCCESS' } } steps { sh 'make test' } } } } uses when with an expression checking if the current build result is success or null (meaning no failure yet), ensuring Test runs only after successful Build.
Step 3: Verify other options
pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { steps { sh 'make test' } } } } runs both stages unconditionally. pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { when { branch 'main' } steps { sh 'make test' } } } } runs Test only on branch 'main' but not based on build success. pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { steps { sh 'make test' } post { always { echo 'Test done' } } } } } runs Test always and adds a post action.