xargs Exit Status: Make Failures Fail CI
xargs reports a documented non-zero exit status when any invoked command fails, so bulk steps fail the build correctly.
For CI it matters that a failed item is not swallowed. xargs has specific exit codes that tell you whether a command failed, was killed, or could not be run.
What it does
xargs runs the command across the items and then exits with a status that encodes the outcome: 0 on full success, and specific non-zero codes when a command failed or could not be started. Under -P this still holds: if any parallel worker fails, xargs exits non-zero after all workers finish.
Common usage
# a single failing curl makes the whole step fail
cat urls.txt | xargs -n 1 curl -fsS; echo "xargs exit: $?"
# stop early on the first failure (no more runs start)
cat urls.txt | xargs -n 1 curl -fsS || exit 1Options
| Exit code | Meaning |
|---|---|
| 0 | All commands succeeded |
| 123 | One or more invocations exited with status 1-125 |
| 124 | A command exited with status 255 |
| 125 | A command was killed by a signal |
| 126 | The command was found but could not be run |
| 127 | The command was not found |
In CI
Make sure xargs is the last command in the pipeline so its exit status is what the step sees; a trailing "| tee log" would mask it (use "set -o pipefail" in bash). Because a failing item yields 123, a flaky bulk step will correctly fail the build instead of passing silently.
Common errors in CI
A bulk step that "passes" despite a failed item usually has something after xargs in the pipe eating the exit code; add set -o pipefail or put xargs last. Seeing 127 means the command was not found (check PATH and the image); 126 means it was found but not executable. 125 means a worker was killed, often the OOM killer under high -P.