A Jenkins pipeline's test stage reports success and the deploy stage runs, even though the test command failed. How does a step failure normally become the build result, and what breaks that chain?

## How failure normally travels Jenkins Pipeline has no return-code model at the stage level. Failure is an exception. A step that fails throws; if nothing on the stack catches it, the stage that contained the step is marked FAILURE, the run's result becomes FAILED, and in Declarative Pipeline the subsequent stages are skipped rather than run. That single sentence is what an interviewer is checking you can say. The most common thrower is `sh`. By default Jenkins runs the script with the shell's `-e` behaviour, so the first failing command ends the script with its status, and a non-zero status makes the step throw. `error('message')` throws explicitly. Most publisher steps throw on genuinely broken input. ## Break one: you asked for the exit code ```groovy def rc = sh(script: 'pytest', returnStatus: true) // the pipeline continues here even when rc == 1 ``` `returnStatus: true` changes the contract: the step returns the exit code and never throws. This is a legitimate feature — sometimes you want to branch on an exit code — but it moves the responsibility for failing the build onto you. The fix is explicit: ```groovy if (rc != 0) { error("tests failed with exit code ${rc}") } ``` A related trap is `returnStdout: true`, which captures output; people reach for one and remember the semantics of the other. ## Break two: the shell hid it Even with a normal `sh`, the *script* can mask the failure: - `make test || true` — someone silenced a noisy step months ago and never removed it. - `pytest | tee test.log` — a shell pipeline's status is the status of the **last** command, and `tee` almost always succeeds, so the step exits 0. `set -o pipefail` before it, or `${PIPESTATUS[0]}` in bash, restores the real status. - A script beginning with its own shebang line (`#!/usr/bin/env bash`) does not get Jenkins' default `-e`, so only the last command's status matters. Add `set -e` yourself. - A trailing command that always succeeds — `run-tests.sh; echo done` — for the same reason. These are the ones that survive code review, because the Jenkinsfile looks correct and the damage is inside the shell script. ## Break three: something downgraded it on purpose ```groovy catchError(buildResult: 'UNSTABLE', stageResult: 'FAILURE') { sh './run-integration-tests.sh' } ``` `catchError` catches the exception and sets the results you name — here the stage shows FAILURE while the build is only UNSTABLE, and the pipeline continues. `warnError('integration tests failed')` is the shorthand for the unstable/unstable case. Both are deliberate tools, and both are exactly how a deploy stage ends up running after a failing test stage when someone tuned the wrapper without thinking about what comes next. A bare `try { } catch (e) { echo e.toString() }` inside a `script` block is the same failure with none of the reporting. ## Break four: UNSTABLE is not FAILURE A publisher such as `junit` typically records test failures by marking the run UNSTABLE rather than FAILED, and the `unstable('reason')` step does the same. UNSTABLE does **not** stop a Declarative pipeline: the remaining stages run normally. If your intent is "never deploy a build with failing tests", set the option explicitly: ```groovy pipeline { options { skipStagesAfterUnstable() } ... } ``` That one line converts a very common silent-deploy into a stopped pipeline. ## Reading the result from inside the pipeline `currentBuild.result` is `null` until something sets it — a fresh, so-far-successful run has no result yet, so `currentBuild.result == 'SUCCESS'` is false in the middle of a green build. `currentBuild.currentResult` gives you `SUCCESS` in that case, which is what conditional logic should read. Getting this backwards produces gates that never fire. ## How to diagnose the reported symptom Open the failing run and look at the *stage* result rather than the console text — the stage view shows whether the test stage was SUCCESS, UNSTABLE or FAILURE, which immediately separates "the failure was swallowed" from "the failure became UNSTABLE and did not stop anything". Then read the actual `sh` invocation for `returnStatus`, and read the shell script for `|| true`, a pipe, or a shebang. One of those four is always the answer.