Today, if an upstream job is blocked and never runs, any downstream job depending on it is stuck — there’s no clean way to say “run this job once everything upstream is done, regardless of the outcome.” This leads to orphaned resources or messy config duplications when trying to implement a workaround.
We’re introducing two new job statuses that downstream jobs can depend on to solve this:
not_run — you can now explicitly condition downstream jobs on not_run, allowing cleanup and fallback jobs to fire whenever an upstream job did not execute.
terminal — an aggregate status that resolves to true when a job has reached any final state: success, failed, canceled, or not_run. Instead of enumerating every possible outcome, you can simply require a job to be terminal.
Here is an example:
workflows:
test:
jobs:
- set-up-test-database
- run-tests:
requires:
- set-up-test-database
- delete-test-database:
requires:
- run-tests: terminal # Runs regardless of outcome
Now, delete-test-database always runs once “run-tests” job have reached a terminal state — whether it succeeded, failed, were canceled, or never ran at all.
For more details, visit the documentation.