Failing builds on test failures in Jenkins - Step-by-Step Execution

Process Flow - Failing builds on test failures

Start Build

↓

Run Tests

↓

Tests Pass?

No→Fail Build

Yes↓

Pass Build

↓

End

The build starts, runs tests, then checks if tests passed. If any test fails, the build fails; otherwise, it passes.

Execution Sample

Jenkins

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        sh 'run-tests.sh'
      }
    }
  }
  post {
    failure {
      echo 'Build failed due to test failures'
    }
  }
}

This Jenkins pipeline runs tests and fails the build if tests fail.

Process Table

Step	Action	Test Result	Build Status	Output
1	Start Build	N/A	Running	Build started
2	Run Tests	Tests running	Running	Executing run-tests.sh
3	Tests Pass?	Fail	Failing	Test failures detected
4	Fail Build	Fail	Failed	Build failed due to test failures
5	End	Fail	Failed	Build stopped

💡 Tests failed, so build fails and stops.

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
Test Result	N/A	Running	Fail	Fail
Build Status	Not started	Running	Failing	Failed

Key Moments - 2 Insights

Why does the build fail even if only one test fails?

Because the build checks the overall test result at Step 3 in the execution table; any failure causes the build to fail immediately.

What happens if all tests pass?

If tests pass at Step 3, the build status changes to Passed and continues to completion without failure.

Visual Quiz - 3 Questions

Look at the execution table, what is the build status at Step 3 when tests fail?

A Passed

B Running

C Failing

D Stopped

💡 Hint

Check the 'Build Status' column at Step 3 in the execution_table.

At which step does the build stop due to test failures?

A Step 2

B Step 5

C Step 3

D Step 4

💡 Hint

Look at the 'Output' and 'Build Status' columns to see when the build stops.

If the tests pass, how would the 'Build Status' change at Step 3?

A Passed

B Failing

C Running

D Failed

💡 Hint

Refer to the key moments explanation about test pass scenario.

Concept Snapshot

Jenkins build runs tests during pipeline.
If any test fails, build status changes to failed.
Use 'post { failure { ... } }' to handle failures.
Build stops immediately on test failure.
Ensures only passing code is deployed.

Full Transcript

In Jenkins, when you run a build pipeline, tests are executed as part of the process. The pipeline checks if tests pass or fail. If any test fails, the build is marked as failed and stops running further steps. This prevents broken code from moving forward. The pipeline can include a post-failure step to notify or log the failure. This flow ensures quality by stopping builds on test failures.

Practice

1. What happens to a Jenkins build if a test command returns a failure exit code?

easy

A. The build restarts the test command automatically.

B. The build ignores the test failure and continues.

C. The build pauses and waits for manual approval.

D. The build fails automatically to indicate test failure.

Solution

1. Step 1: Understand Jenkins build behavior on command failure

   Jenkins treats any shell or batch command that returns a non-zero exit code as a failure.

2. Step 2: Relate test command failure to build status

   If tests fail and return a failure code, Jenkins marks the entire build as failed automatically.

3. Final Answer:

   The build fails automatically to indicate test failure. -> Option D

4. Quick Check:

   Test failure exit code causes build failure [OK]

Hint: Non-zero exit code from tests fails the build [OK]

Common Mistakes:

• Thinking Jenkins ignores test failures by default
• Assuming manual intervention is needed on test failure
• Believing Jenkins retries failed test commands automatically

2. Which of the following Jenkins pipeline syntax snippets correctly fails the build if tests fail?

easy

A. sh 'run_tests.sh & wait' // runs tests in background

B. sh 'run_tests.sh || true' // ignores test failures

C. sh 'run_tests.sh' // fails build if script exits non-zero

D. sh 'run_tests.sh; echo done' // always succeeds

Solution

1. Step 1: Analyze each shell command's effect on build status

   sh 'run_tests.sh' // fails build if script exits non-zero runs the test script normally; if it exits non-zero, Jenkins fails the build.

2. Step 2: Identify commands that ignore failure

   sh 'run_tests.sh || true' // ignores test failures uses '|| true' which forces success, ignoring failures; C runs in background, not failing build; D always succeeds due to echo.

3. Final Answer:

   sh 'run_tests.sh' // fails build if script exits non-zero -> Option C

4. Quick Check:

   Normal shell command fails build on error [OK]

Hint: Avoid '|| true' to let Jenkins catch test failures [OK]

Common Mistakes:

• Adding '|| true' to shell commands
• Running tests in background without waiting
• Appending commands that always succeed after tests

3. Given this Jenkins pipeline snippet, what will be the build result if pytest finds failing tests?

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        sh 'pytest'
      }
    }
  }
}

medium

A. Build will succeed regardless of test results.

B. Build will fail if pytest returns a failure exit code.

C. Build will be unstable but not fail.

D. Build will skip the test stage.

Solution

1. Step 1: Understand Jenkins behavior on shell step failure

   The sh step fails the build if the command exits with a non-zero code.

2. Step 2: Recognize pytest exit codes

   pytest returns non-zero exit code if any test fails, causing Jenkins to fail the build.

3. Final Answer:

   Build will fail if pytest returns a failure exit code. -> Option B

4. Quick Check:

   Failing tests cause non-zero exit, fail build [OK]

Hint: Test commands returning non-zero fail build [OK]

Common Mistakes:

• Assuming build passes despite test failures
• Confusing unstable with failed build
• Thinking Jenkins skips failing test stages

4. You have a Jenkins pipeline where tests fail but the build still shows as SUCCESS. What is the most likely cause?

medium

A. The test command is run with '|| true' which ignores failures.

B. The pipeline is missing the 'agent any' declaration.

C. The Jenkins server is offline during the test stage.

D. The post section is configured to always mark build as success.

Solution

1. Step 1: Identify why build ignores test failures

   Using '|| true' after test commands forces success regardless of test results.

2. Step 2: Exclude other causes

   Missing 'agent any' causes pipeline failure, server offline stops build, post section can't override success if test fails.

3. Final Answer:

   The test command is run with '|| true' which ignores failures. -> Option A

4. Quick Check:

   '|| true' masks test failures causing success [OK]

Hint: Check for '|| true' masking failures in shell steps [OK]

Common Mistakes:

• Blaming missing agent for test failure ignoring
• Assuming Jenkins server offline lets build succeed
• Misconfiguring post section to override failure

5. How can you configure a Jenkins declarative pipeline to always run tests but mark the build as UNSTABLE instead of FAILED when tests fail?

hard

A. Use post { always { junit '**/test-results.xml' } } and catchError(buildResult: 'UNSTABLE') around test step.

B. Add sh 'run_tests.sh || true' to ignore failures.

C. Set options { skipStagesAfterUnstable() } in pipeline.

D. Use post { failure { echo 'Tests failed' } } without changing build status.

Solution

1. Step 1: Use catchError to catch test failures and mark build unstable

   Wrapping test commands with catchError(buildResult: 'UNSTABLE') prevents build failure but marks unstable.

2. Step 2: Use post section to publish test results

   Publishing test results with junit reports test failures and sets build status accordingly.

3. Final Answer:

   Use post { always { junit '**/test-results.xml' } } and catchError(buildResult: 'UNSTABLE') around test step. -> Option A

4. Quick Check:

   catchError + junit marks unstable, not failed [OK]

Hint: Use catchError(buildResult: 'UNSTABLE') to mark unstable [OK]

Common Mistakes:

• Ignoring test failures with '|| true' instead of marking unstable
• Misusing post failure block without changing status
• Skipping test stages after unstable status