Stage block structure in Jenkins - Commands & Configuration

Introduction

When you want to organize your Jenkins pipeline into clear steps, you use stage blocks. Each stage represents a part of your process, like building or testing, making it easier to see progress and find problems.

When you want to separate your pipeline into logical steps for clarity.

When you need to run different tasks like build, test, and deploy in order.

When you want Jenkins to show progress visually in the pipeline view.

When you want to add conditions or parallel tasks inside specific stages.

When you want to easily identify which part of the pipeline failed.

Config File - Jenkinsfile

Jenkinsfile

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building the application'
            }
        }
        stage('Test') {
            steps {
                echo 'Running tests'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying the application'
            }
        }
    }
}

This Jenkinsfile defines a pipeline with three stages: Build, Test, and Deploy.

The pipeline block is the main container.

The agent any means Jenkins can run this pipeline on any available agent.

The stages block holds multiple stage blocks, each representing a step in the process.

Inside each stage, the steps block contains the commands to run.

Commands

Check that Jenkins job builder is installed and accessible before running pipelines.

Terminal

jenkins-jobs --version

Expected Output

1.0.0

Start the Jenkins pipeline named 'example-pipeline' which uses the Jenkinsfile with stage blocks.

Terminal

jenkins-cli build example-pipeline

Expected Output

[Pipeline] Start of Pipeline

[Pipeline] stage

[Pipeline] { (Build)

Building the application

[Pipeline] }

[Pipeline] stage

[Pipeline] { (Test)

Running tests

[Pipeline] }

[Pipeline] stage

[Pipeline] { (Deploy)

Deploying the application

[Pipeline] }

[Pipeline] End of Pipeline

View the console output of the running or completed pipeline to see the output of each stage.

Terminal

jenkins-cli console example-pipeline

Expected Output

Building the application

Running tests

Deploying the application

Key Concept

If you remember nothing else from this pattern, remember: stage blocks divide your pipeline into clear, named steps that show progress and organize tasks.

Common Mistakes

Not wrapping steps inside a stage block

Jenkins will fail to run the pipeline or stages won't show up in the UI.

Always put commands inside a stage block within the stages section.

Missing the steps block inside a stage

Jenkins expects steps to be inside the steps block; otherwise, it throws syntax errors.

Wrap all commands inside a steps block inside each stage.

Using stages outside the pipeline block

The pipeline block is the root; stages must be inside it or Jenkins will reject the file.

Always place stages inside the pipeline block.

Summary

Stage blocks organize Jenkins pipelines into named steps for clarity and progress tracking.

Each stage must have a steps block containing the commands to run.

Stages go inside the stages block, which is inside the pipeline block.

Practice

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

1. 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.

2. Step 2: Compare with other pipeline blocks

   Other blocks like environment or agent serve different purposes, not organizing steps.

3. Final Answer:

   To divide the pipeline into named steps for better organization and tracking -> Option B

4. 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

1. Step 1: Recall correct stage block syntax

   The correct syntax uses stage('Name') { steps { ... } } with curly braces and plural steps.

2. 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.

3. Final Answer:

   stage('Build') { steps { sh 'make' } } -> Option C

4. Quick Check:

   Correct stage syntax = stage('Build') { steps { sh 'make' } } [OK]

Hint: Remember: stage('name') { steps { ... } } [OK]

Common Mistakes:

• Using colon instead of braces
• Writing singular 'step' instead of 'steps'
• Omitting braces around steps block

3. Given this Jenkins pipeline snippet, what will be the output in the console for the Test stage?

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        echo 'Running tests'
      }
    }
  }
}

medium

A. No output

B. Test stage skipped

C. Syntax error in pipeline

D. Running tests

Solution

1. Step 1: Analyze the pipeline snippet

   The pipeline defines a single stage named 'Test' with a step that echoes 'Running tests'.

2. Step 2: Understand echo behavior in Jenkins

   The echo command prints the given string to the console output during the stage execution.

3. Final Answer:

   Running tests -> Option D

4. 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

1. Step 1: Check the block keyword inside stage

   The correct keyword to wrap commands inside a stage is steps (plural), not step.

2. Step 2: Verify other options

   Stage names can be any case, sh is valid inside steps, and agent is optional if defined globally.

3. Final Answer:

   The block should use steps instead of step -> Option A

4. 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

1. 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.

2. 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.

3. 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.

4. Final Answer:

   pipeline { agent any; stages { stage('Build') { steps { sh 'make' } } stage('Test') { when { expression { currentBuild.result == null || currentBuild.result == 'SUCCESS' } } steps { sh 'make test' } } } } -> Option A

5. Quick Check:

   Use 'when' with build result for conditional stages [OK]

Hint: Use 'when' block to run stage only on success [OK]

Common Mistakes:

• Assuming stages run conditionally by default
• Using branch condition instead of build result
• Missing 'when' block for conditional execution