In GitHub Actions, why is a final cleanup step skipped when an earlier step fails?

## The implicit condition The single sentence that explains the whole bug: **a GitHub Actions step without an `if:` key runs only if every previous step in the job succeeded.** The absence of a condition is itself a condition, functionally `if: success()`. So a job written in the obvious order — ``` - run: docker compose up -d - run: ./gradlew integrationTest - run: docker compose down ``` — tears down the environment exactly when it did not need tearing down, and leaks it every time the tests fail. On a hosted runner that leak is mostly harmless because the machine is discarded, but on a self-hosted runner it poisons the next job, and the same shape applies to revoking a lease, releasing a lock, closing a maintenance window, or uploading the log file that would have told you why the tests failed. ## The status check functions GitHub provides four functions usable in an `if:`: - `success()` — true when no previous step (or, at job level, no dependency) has failed. The implicit default. - `failure()` — true when a previous step failed. Use for notify-on-broken-build and diagnostics dumps. - `cancelled()` — true when the run has been cancelled. - `always()` — true unconditionally, including during cancellation. They compose with normal boolean operators, and `if:` accepts an expression with or without the `${{ }}` wrapper. The three idioms worth memorising: | Intent | Condition | |---|---| | Always tear down | `if: always()` | | Tear down, but let cancel win | `if: !cancelled()` | | Only on the failure path | `if: failure()` | ## `always()` versus `!cancelled()` `always()` is the blunt instrument, and GitHub's own documentation advises against it for anything long-running: a step marked `always()` keeps executing after a cancellation is requested, so a cancelled run does not actually stop when the operator expects it to. `!cancelled()` gives you the same success-and-failure coverage while letting cancellation take effect. Reach for `always()` only when the cleanup genuinely must happen even on cancel — releasing a shared lock is the classic legitimate case. ## Combining with a condition of your own A subtlety that trips people: as soon as you write *any* `if:`, the implicit success gate is gone. So ``` if: github.ref == 'refs/heads/main' ``` on a deploy step does **not** silently keep "...and everything before succeeded" — except that at step level the status functions are still implied unless you use one. The safe habit is to be explicit about both halves when you mean both: ``` if: always() && github.event_name == 'push' ``` and to read any condition you write as the complete truth about when the step runs. ## The same problem one level up Jobs behave identically. A job with `needs: [test]` is skipped when `test` fails, so a `cleanup` or `notify` job needs `if: always()` (or `!cancelled()`) to run at all. Once it does run, it can inspect `needs.test.result` to decide what to say. The pattern: ``` notify: needs: [build, test] if: failure() runs-on: ubuntu-latest steps: - run: ./notify.sh "build=${{ needs.build.result }} test=${{ needs.test.result }}" ``` ## Neighbouring mechanics people confuse with this **`continue-on-error: true`** on a step means the step's failure does not fail the job — so later steps still run *and the job can still be green*. That is a different tool: it hides a failure rather than guaranteeing cleanup. When you use it, `steps.<id>.outcome` holds what really happened (`failure`) while `steps.<id>.conclusion` holds what the job was told (`success`), and inspecting `outcome` is how you branch on the real result. **Post steps.** Some actions register their own cleanup that runs at the end of the job regardless — `actions/checkout` removing its credentials is the familiar example. That is the action's own guarantee, not something your `run:` step inherits, so it does not save your teardown script. **Timeouts and cancellation.** A job killed by `timeout-minutes` or by a cancellation is not a step failure, which is precisely why `always()` and `!cancelled()` differ, and why a teardown that matters under timeout needs `always()`. ## The interview answer in one breath Steps default to "only if everything before me passed"; cleanup is by definition the thing that must run when something before it did not pass; therefore cleanup always carries an explicit `if:`, and which of `always()`, `!cancelled()` or `failure()` you choose is a statement about cancellation and about whether the step is diagnostics or teardown.