A Green Workflow Can Still Contain a Failed Audit
A volunteer-run community museum maintains an accessible online event calendar. Its deployment workflow runs link validation, checks missing image alt text and performs an experimental color-contrast scan. The experimental scanner may generate false positives, so maintainers consider allowing that step to fail without turning the entire job red. GitHub Actions provides continue-on-error at step and job scope, but the choice changes how failure is reflected downstream. A green job is not proof that every underlying check passed. For an accessible public-facing website, distinguish advisory findings from release-blocking defects and preserve the original status of any step that was allowed to fail.
Learn the Difference Between outcome and conclusion
GitHub documents two relevant properties for a step with an ID. steps.
Keep Mandatory Checks Outside the Advisory Path
Start by listing release requirements. Broken critical navigation, missing legal notices and failed build integrity checks may need to block deployment. A new, noisy heuristic contrast checker can be advisory while the team calibrates it. Place continue-on-error only on the specific experimental step rather than at workflow level or on an entire quality job. Retain required status checks for stable, tested rules. If a critical check is repeatedly failing, resolve the issue or revise the policy explicitly; do not make it optional just to regain a green dashboard. A consistent policy should be understood by designers, translators and repository administrators before enabling automatic releases.
Build a Separate Advisory Evidence Summary
After the optional scanner runs, add a reporting step that captures whether the underlying scan succeeded or failed. GitHub’s steps context can expose the original outcome even when the step’s conclusion is success for workflow continuation. Store a limited, sanitized report artifact with affected pages and rule IDs. Avoid uploading full private draft pages if an issue identifier and location are enough. Use a summary to make advisory findings visible to maintainers without implying that a human performed an accessibility review. If the scanner crashes, label the report ‘scan did not complete’ rather than ‘no problems found.’ Distinguish tool errors, genuine violations and intentionally skipped checks.
Compare Three States Rather Than Two Colors
Imagine a quality dashboard with an advisory scanner that passed, an advisory scanner that found issues and was allowed to fail, and a required navigation check that failed. The second should not silently look identical to the first just because the job remains green. The third should block the protected release path. The illustration compares intended status semantics and does not depict a live GitHub run. Use explicit fields such as advisory_outcome, critical_checks_passed and reviewer_approved. A release decision should be a documented expression over required tests plus human approval when appropriate, not a loose interpretation of overall workflow color.
Plan for Steps That Are Skipped or Never Started
A step outcome may be skipped because its condition evaluated false, while a runner interruption may stop a job before reporting occurs. Neither means the underlying audit passed. Use explicit status checks and suitable conditional expressions for reporting, while respecting GitHub’s execution behavior. Be careful that default success conditions can suppress later steps after a failure; an intentional report step may need an explicit status condition. Verify that the reporting action itself does not hold broad repository write credentials. For a release pipeline, incomplete evidence should resolve to a review-required state, not to automatic acceptance.
Avoid Reusing Advisory Status as a Release Dependency
A downstream deploy job that needs only the advisory job’s apparent success can accidentally treat a tolerated failure as a clean bill of health. Instead, make the deployment depend on genuinely required jobs and protected environment or approval rules. If advisory findings must influence the final decision, pass a structured output that preserves the underlying failure and have the publisher evaluate it explicitly. Be mindful of output propagation, skipped dependencies and any condition that can bypass normal failed-job behavior. The correct design is visible in a dependency graph: advisory scan feeds a report, mandatory checks feed a release gate, and reviewers can see both.
Run Failure-Injection Tests Before Relying on the Gate
Use a small synthetic site fixture with one deliberately low-contrast component, one broken keyboard focus order, and a clean baseline. Confirm that the experimental scanner’s failure is reported through steps.
Use Green to Mean What the Policy Actually States
A public museum’s visitors rely on usable navigation, captions and readable text. Optional checks are reasonable during adoption, but they should become mandatory once the team has validated their reliability and established a remediation process. Revisit the advisory list at a documented interval and track whether unresolved findings are accumulating. Link each release to the source commit, the mandatory test results, the advisory report and any human signoff. Avoid statements such as ‘accessibility verified’ when only automated heuristics ran. continue-on-error is a control for pipeline behavior; meaningful accessibility requires actual review, representative assistive-technology testing and an honest release standard.
How We Research
We reviewed the named official primary sources on November 8, 2026: GitHub Actions workflow syntax, GitHub Actions contexts reference, GitHub Actions expressions. We compared documented parameter scope, practical boundary cases and implementation risks with the review workflow in this article. We checked the topic and slug against the WordPress title inventory supplied by LabFin and previous B0267–B0272 batches. We did not authenticate to a vendor account, run a live API request, conduct a performance benchmark, review real confidential archive material or verify deployment outcomes. All documents, sample states and diagrams are hypothetical teaching illustrations; product UI is not reproduced.
Frequently Asked Questions
No. A failed step can have outcome failure and conclusion success after the setting is applied.
Apply it narrowly to the advisory step, not broadly to mandatory release checks.
Give it an id and inspect steps.<id>.outcome in later reporting logic.
No. Skipped and incomplete checks require explicit handling rather than being treated as clean results.
That is a policy decision; keep mandatory gating explicit, and preserve advisory evidence for review.