The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →A zero exit status means the command or operation observed at a particular boundary reported success. It does not prove that every earlier command succeeded, or that the artifact, test report, or deployment you wanted actually exists. The mismatch usually comes from how a command list, CI wrapper, or pipeline selects and reports status.
What does exit 0 actually tell you?
It tells you that the operation whose status you observed reported success according to its own semantics. It is not a retrospective audit of every command that ran before it. A shell can report the status of a list or pipeline rather than the status of each command inside it. The POSIX shell specification and Bash manual describe these status rules, but Bash-specific behavior should not be assumed for every shell. POSIX shell command language and the Bash Reference Manual document the relevant rules.
As an Amazon Associate I earn from qualifying purchases.
Three ways a failure can disappear
| Pattern | Where the reported status comes from | Failure at risk | How to make it visible |
|---|---|---|---|
| Commands combined in a CI string | GitLab documents that only the last command’s result is reported when multiple commands are combined into one command string. | An earlier command fails, then a later command succeeds. | Use separate script items or explicitly propagate failure. |
| AND list in a CI job | The list and runner handling determine the job result. | A command in the list fails, but the job is still reported successful in GitLab’s documented example. | Follow GitLab’s documented grouping workaround and check the active runner behavior. |
| Pipeline | The shell’s pipeline status rules select the result; defaults differ by shell. | An upstream command fails while the final command succeeds. | Use an appropriate shell-specific pipeline failure setting, or otherwise propagate the upstream failure. |
GitLab’s Scripts and job logs documentation describes the CI cases below. These are documented behaviors, not a guarantee that every runner or shell behaves identically.
1. A later command can replace the status you care about
Suppose a CI command string runs a build and then a cleanup command. If the build fails but cleanup succeeds, the reported status may be cleanup’s success. GitLab states: “If multiple commands are combined into one command string, only the last command’s failure or success is reported.” The failure is not undone; it simply is not the result reported for that combined string.
#1 Best Overall
Where practical, put commands in separate CI script items so the CI system can handle each item distinctly. Otherwise, explicitly stop or propagate failure after a required command fails. Confirm how your runner interprets the command string rather than assuming an earlier nonzero status will remain visible.
2. An AND list may not fail the job as expected
Developers often expect first-command && second-command to make a CI job fail whenever either command fails. GitLab documents a case with invalid commands joined by && where the job can nevertheless be reported as successful, and recommends grouping the line in parentheses to make failure propagate.
Rank #2
That example is a warning about the complete command line and runner handling, not a claim that && ignores failures in every shell context. Apply the documented grouping workaround when it matches your GitLab setup, then verify the result with the shell and runner configuration used by the job.
Free tools Windows power users keep installed
One-click scans. No signup required.
3. A pipeline can report the last command’s status
In a pipeline, such as missing-tool | cat, the upstream command can fail while cat exits successfully. Under the ordinary pipeline status rule in many shells, including Bash when pipefail is not enabled, the pipeline status is the status of its last command. The status observed for the pipeline can therefore be zero even though missing-tool was not found.
POSIX specifies pipeline status behavior; Bash also documents the pipefail option, which makes a pipeline return a failure status when a command in it fails (with the status determined by Bash’s rule). That option is Bash-specific and should not be treated as a portable POSIX setting. Check which shell actually executes the script, enable the relevant failure behavior where supported, or explicitly capture and propagate the upstream status.
Quick Recap
How to trace a false success in a script or CI job
- Find the reporting boundary. Identify the exact command string, CI script item, shell list, pipeline, or wrapper whose status becomes the job result.
- Inspect commands before that boundary. Look for a later successful command that can become the reported status, an AND list handled by the runner, or a pipeline whose final command succeeds.
- Check the execution environment. Confirm the shell, runner, and CI configuration. A Bash option does not automatically apply to a different shell, and CI wrappers can affect how status is handled.
- Make propagation explicit. Separate CI commands where appropriate, use the runner’s documented grouping or failure-handling mechanism, and configure pipeline handling for the active shell.
- Verify the intended result independently. If success means an artifact was produced, a test report exists, or a deployment changed the target, check for that result rather than treating exit status as proof of it.
What to remember when reading a green job
- A zero is a report from a particular command or execution boundary, not proof that all earlier work succeeded.
- Lists, pipelines, and CI wrappers can report a different status from an individual command inside them.
- Find out which status the runner receives, then make required failure propagation explicit.
- When the goal is an external result, verify that result separately.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
