Changing every downstream job to always() can blur those two purposes. First write down which job should still run and what it is allowed to do.
Separate a report from a release gate
This original diagnostic workflow intentionally fails a test placeholder and then reports that job's result. It contains no release step or repository checkout:
name: Dependency demonstration
on: workflow_dispatch
permissions: {}
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Deliberate teaching failure
run: exit 1
report:
needs: test
if: ${{ always() }}
runs-on: ubuntu-latest
steps:
- name: Report test conclusion
env:
TEST_RESULT: ${{ needs.test.result }}
run: |
printf 'test result: %s\n' "$TEST_RESULT"
GitHub's workflow syntax reference, checked October 24, 2026, describes dependency behavior and the explicit condition used to continue a dependent job. Its job-condition guide explains the job-level if field.
Under an ordinary uncancelled run where the runner executes both jobs, the authored expectation is test=failure and report output containing test result: failure. Without the explicit condition, a job depending on the failed test would ordinarily be skipped. These are expected results for a teaching fixture, not a receipt from a GitHub run.
always() controls the condition evaluation; it does not guarantee a runner, reverse a cancellation or make every step complete. Keep the report small and independent of artifacts that a failed earlier job might never produce.
Keep release eligibility explicit
For a release that requires successful tests, retain the appropriate successful dependency rule. Do not copy the diagnostic report's condition onto that release just to make a skipped badge disappear. If a workflow has several prerequisites, list each one and the required outcome before changing the condition.
| Upstream observation | Reporting question | Release question |
|---|---|---|
| Test failed | Can the report describe the failure without missing artifacts? | Is the release correctly prevented? |
| Test succeeded | Does the report describe the actual success? | Have all other prerequisites also succeeded? |
| Test skipped or run cancelled | What evidence, if any, is available? | What explicit policy covers this state? |
The table is a review policy, not a replacement for the workflow's actual events and permissions. A job can be skipped for a condition that has nothing to do with a test failure.
Copy the dependency-review prompt
Explain why this GitHub Actions job was skipped. Do not edit yet.
Full relevant workflow, including on, needs, if and permissions: [PASTE]
Actual event/ref and job conclusions from the run: [PASTE]
Intended report behavior after success/failure/skip/cancellation: [ENTER]
Release or deployment gates that must remain intact: [ENTER]
Trace each dependency and condition. Separate observed conclusions
from hypotheses. Propose the smallest change for the reporting job
only, with expected outcomes for the stated cases. Do not broaden
events or permissions, expose secrets, change release conditions, or
claim a workflow ran. Explain missing artifacts the report relies on.
OpenAI's prompting guidance describes using context and boundaries to shape a request. Here, a useful boundary is the exact job whose behavior may change.
Review the proposed YAML in a test workflow and compare its real job conclusions with the expected cases before adopting it. For quoting inside one run step, use the shell-script guide. Keep the job-dependency explanation with the workflow so a later cleanup preserves both diagnostic reporting and the release gate.