Why can a CI job pass when the build failed, and how do pipes, pipefail, set -e and PIPESTATUS change that?

In a shell pipeline the exit status is by default the status of the last command. The classic iOS case is xcodebuild … | xcpretty or | tail: the formatter succeeds, so the step reports success even though the build failed. The check shows it with a real xcodebuild pointed at a missing project: with | tail -1 the status printed is 0, with set -o pipefail it is non-zero. pipefail makes the pipeline return the status of the rightmost failing command; PIPESTATUS (bash) holds every stage’s status (0 1 0 in the check); and set -e on its own does not stop the script for a failing earlier stage of a pipeline, while set -eo pipefail does (the last line of the check never runs).

The standard header for a release script is set -euo pipefail: exit on a failed command, on an unset variable and on a failed pipeline stage. Some CI systems run each step with sh -e only, without pipefail, so put the header in your own script, written in bash, and keep logic out of inline YAML one-liners (Q480). Also: log the exit status of the tool, not of the formatter (formatters often accept a flag to preserve the result), save the raw log as an artefact so the formatted one cannot hide the failure, and add a step that checks the artefact exists (an archive, an ipa) instead of trusting the previous step. Beware the opposite problem too: grep that finds nothing returns 1, so a pipeline that legitimately finds no matches fails under pipefail; handle it explicitly. Checked with bash and the system sh on macOS; other shells differ in the details of PIPESTATUS.