Bird
Raised Fist0
Jenkinsdevops~5 mins

Post section (success, failure, always) in Jenkins - Time & Space Complexity

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime
Time Complexity: Post section (success, failure, always)
O(1)
Understanding Time Complexity

We want to understand how the time taken by a Jenkins pipeline changes when using the post section with success, failure, and always blocks.

Specifically, how does adding these blocks affect the overall execution time as the pipeline grows?

Scenario Under Consideration

Analyze the time complexity of the following Jenkins pipeline snippet.

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        echo 'Building...'
      }
    }
  }
  post {
    success {
      echo 'Success!'
    }
    failure {
      echo 'Failure!'
    }
    always {
      echo 'Always runs'
    }
  }
}

This pipeline runs a build stage and then runs different post blocks depending on the build result.

Identify Repeating Operations

Look for repeated actions or loops in the post section.

  • Primary operation: The post section runs exactly one of the success or failure blocks, plus the always block.
  • How many times: Each post block runs once per pipeline execution, no loops or recursion.
How Execution Grows With Input

The post section runs a fixed number of steps regardless of pipeline size.

Input Size (n)Approx. Operations
103 (success/failure + always)
1003
10003

Pattern observation: The number of post steps does not grow with input size; it stays constant.

Final Time Complexity

Time Complexity: O(1)

This means the post section runs a fixed number of steps no matter how big the pipeline or input is.

Common Mistake

[X] Wrong: "The post section runs multiple times and grows with the number of stages or steps."

[OK] Correct: The post section runs only once after the entire pipeline finishes, so its execution time does not increase with pipeline size.

Interview Connect

Understanding fixed versus growing execution parts in pipelines helps you design efficient CI/CD workflows and explain your reasoning clearly in interviews.

Self-Check

"What if the post section contained loops or calls to other jobs? How would that affect the time complexity?"

Practice

(1/5)
1. What is the purpose of the post section in a Jenkins pipeline?
easy
A. To run steps after the main pipeline or stage finishes
B. To define environment variables for the pipeline
C. To specify the build agent for the pipeline
D. To declare input parameters for the pipeline

Solution

  1. Step 1: Understand the role of the post section

    The post section is designed to run steps after the main pipeline or stage finishes, regardless of success or failure.

  2. Step 2: Compare with other pipeline sections

    Other sections like environment, agent, and parameters serve different purposes, not for post-run steps.

  3. Final Answer:

    To run steps after the main pipeline or stage finishes -> Option A

  4. Quick Check:

    Post section = run after pipeline [OK]
Hint: Post section always runs after pipeline ends [OK]
Common Mistakes:
  • Confusing post with environment or agent sections
  • Thinking post runs before pipeline starts
  • Assuming post only runs on failure
2. Which of the following is the correct syntax to run a step only when the pipeline succeeds in the post section?
easy
A. post { always { echo 'Done' } }
B. post { success { echo 'Build succeeded' } }
C. post { failure { echo 'Build failed' } }
D. post { cleanup { echo 'Cleaning up' } }

Solution

  1. Step 1: Identify the correct post condition for success

    The success block runs only when the pipeline finishes successfully.

  2. Step 2: Check syntax correctness

    post { success { ... } } is the correct syntax. Other options use wrong conditions or invalid keywords.

  3. Final Answer:

    post { success { echo 'Build succeeded' } } -> Option B

  4. Quick Check:

    Success block runs on success [OK]
Hint: Use 'success' block for success-only steps [OK]
Common Mistakes:
  • Using 'always' instead of 'success' for success-only steps
  • Using invalid keywords like 'cleanup'
  • Confusing 'failure' with 'success'
3. Given this Jenkins pipeline snippet, what will be printed if the build fails? 
pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        sh 'exit 1'
      }
    }
  }
  post {
    success {
      echo 'Build succeeded'
    }
    failure {
      echo 'Build failed'
    }
    always {
      echo 'Build finished'
    }
  }
}
medium
A. Build failed Build finished
B. Build succeeded
C. Build succeeded Build finished
D. Build finished

Solution

  1. Step 1: Analyze the build result

    The shell command sh 'exit 1' causes the build to fail.

  2. Step 2: Determine which post blocks run on failure

    The failure block runs on failure, printing 'Build failed'. The always block runs regardless, printing 'Build finished'. The success block does not run.

  3. Final Answer:

    Build failed Build finished -> Option A

  4. Quick Check:

    Failure + always blocks run on failure [OK]
Hint: Failure and always blocks run on failure [OK]
Common Mistakes:
  • Assuming success block runs on failure
  • Ignoring the always block
  • Thinking only failure block runs
4. Identify the error in this Jenkins pipeline post section: 
post {
  success {
    echo 'Success!'
  }
  failure {
    echo 'Failure!'
  }
  always {
    echo 'Always runs'
  }
  cleanup {
    echo 'Cleaning up'
  }
}
medium
A. The 'always' block should be named 'alwaysRun'
B. The 'failure' block must come before 'success'
C. The 'cleanup' block is invalid in the post section
D. The 'echo' commands must be inside 'steps' block

Solution

  1. Step 1: Review valid post condition blocks

    Valid blocks are success, failure, always, unstable, and changed. There is no cleanup block.

  2. Step 2: Check syntax of echo commands

    The echo commands can be used directly in post blocks. The order of blocks does not matter.

  3. Final Answer:

    The 'cleanup' block is invalid in the post section -> Option C

  4. Quick Check:

    Only success, failure, always allowed [OK]
Hint: Post section allows only specific blocks like success, failure, always [OK]
Common Mistakes:
  • Adding unsupported blocks like 'cleanup'
  • Thinking block order matters
  • Wrapping echo in steps inside post (not needed)
5. You want to send a notification only if the build fails, but also always archive the build logs regardless of the result. Which post section correctly implements this?
hard
A. post { failure { mail to: 'team@example.com' archiveArtifacts 'logs/**' } }
B. post { always { mail to: 'team@example.com' } failure { archiveArtifacts 'logs/**' } }
C. post { success { mail to: 'team@example.com' } always { archiveArtifacts 'logs/**' } }
D. post { failure { mail to: 'team@example.com' } always { archiveArtifacts 'logs/**' } }

Solution

  1. Step 1: Identify notification condition

    Notification should run only on failure, so it belongs in the failure block.

  2. Step 2: Identify archiving condition

    Archiving logs should happen always, so it belongs in the always block.

  3. Step 3: Check syntax correctness

    post { failure { mail to: 'team@example.com' } always { archiveArtifacts 'logs/**' } } correctly separates the two actions into failure and always blocks. post { failure { mail to: 'team@example.com' archiveArtifacts 'logs/**' } } puts both actions in the failure block, so archiving occurs only on failure.

  4. Final Answer:

    post { failure { mail to: 'team@example.com' } always { archiveArtifacts 'logs/**' } } -> Option D

  5. Quick Check:

    Failure for notify, always for archive [OK]
Hint: Use failure for notify, always for archive [OK]
Common Mistakes:
  • Putting always steps inside failure block
  • Sending notifications on success instead of failure
  • Missing proper syntax for multiple steps
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard