GitHub Actions Pipeline Failure Masked - pipefail Not Set in run:
A step reports success even though a command in a pipeline failed, because only the last command's exit status counts unless pipefail is set. Overriding the shell, or piping to tee, can drop the default safety and mask real failures.
What this error means
A run step ends green while an earlier command in a pipe (a build, a test, a generator) actually failed, because the pipeline's exit status came from the last stage (often tee or grep), not the failing command.
- run: ./run-tests.sh | tee results.log
shell: sh # custom shell drops the default bash pipefail
# tests fail, but tee exits 0, so the step passesDiagnose it: print the context before you change anything
Most workflow-expression bugs are not syntax errors, they are an expression reading something that is empty. GitHub resolves a missing property to an empty string instead of failing the run, so a wrong reference looks like a logic bug rather than a mistake. Dump the contexts first and you will usually see the answer immediately.
- name: Dump contexts
run: |
echo '--- github ---' ; echo '${{ toJSON(github) }}'
echo '--- needs ---' ; echo '${{ toJSON(needs) }}'
echo '--- steps ---' ; echo '${{ toJSON(steps) }}'
echo '--- matrix ---' ; echo '${{ toJSON(matrix) }}'
echo '--- inputs ---' ; echo '${{ toJSON(inputs) }}'Check the context is allowed where you used it
Contexts are not available everywhere. The same expression can be valid in a step if and invalid in a job if, which is why an expression that works in one workflow fails when moved.
| Where you wrote it | Contexts available there |
|---|---|
run-name | github, inputs, vars |
concurrency | github, inputs, vars |
Top-level env | github, secrets, inputs, vars |
jobs.<id>.if | github, needs, vars, inputs |
jobs.<id>.steps.if | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs |
jobs.<id>.outputs | Full access, including secrets |
Reusable workflow outputs | github, jobs, vars, inputs |
Common causes
A custom shell removes the default flags
GitHub runs bash steps with set -eo pipefail by default. Specifying shell: sh (or a custom shell line) replaces those defaults, so a failing piped command is no longer caught.
Last-stage exit status wins
Without pipefail, a pipeline reports the exit code of its last command. Piping a failing command to tee, grep, or sort hides the upstream failure.
How to fix it
Keep or restore pipefail
Use the default bash shell, or set the flags yourself when overriding the shell.
- run: |
set -eo pipefail
./run-tests.sh | tee results.logSet defaults at the job level
- Add defaults.run.shell: bash so steps keep pipefail without per-step overrides.
- When a step truly needs sh, add set -e and check ${PIPESTATUS[0]} or restructure to avoid masking.
- Avoid ending a pipeline with a command that always exits 0 unless you have checked the upstream status.
Catch it before it reaches CI
Every failure in this cluster is statically detectable. actionlint parses workflow expressions, checks context availability against the same rules above, and validates needs references, so these bugs never need to cost you a run.
# one-off
docker run --rm -v "$(pwd):/repo" --workdir /repo rhysd/actionlint:latest -color
# as a job, before anything expensive runs
- uses: actions/checkout@v4
- run: |
bash <(curl -s https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash)
./actionlint -colorHow to prevent it
- Keep the default bash shell so pipefail stays on.
- When overriding shell:, re-add set -eo pipefail explicitly.
- Avoid piping failing commands into tee/grep without checking PIPESTATUS.