parity-aggregate's if: condition uses !cancelled(), which removes the implicit "all needs succeeded" gate that GitHub Actions otherwise applies. The job therefore runs even when the parity job it aggregates never ran at all, and fails with nothing to aggregate.
How it surfaces
It is normally invisible, because parity normally runs. It needs three things at once:
- the
run-extended-tests label, which forces plan.jobs.parity=true;
- an upstream failure that causes
parity to be skipped rather than run — for example a failing check;
parity-aggregate then running anyway, because !cancelled() is true.
Observed on PR #10354 with exactly that combination. Fixing the upstream check failure resolves it, so it is not blocking anything — but it means a red parity-aggregate can be pure noise, pointing at a job that never executed.
Fix
Test the dependency's actual result rather than only cancellation:
if: ${{ !cancelled() && needs.parity.result == 'success' }}or whichever result set is intended (success / skipped). The point is that !cancelled() alone silently opts out of dependency checking, which is rarely what an aggregator wants.
Worth auditing the other jobs using a bare !cancelled() at the same time — the pattern is used elsewhere in test.yml, and each use should be a deliberate choice to run despite a failed dependency rather than an accident.
Provenance
Found while triaging CI on PR #10354. The wiring is byte-identical to main, so this is a latent defect in main rather than anything that branch introduced.
parity-aggregate'sif:condition uses!cancelled(), which removes the implicit "allneedssucceeded" gate that GitHub Actions otherwise applies. The job therefore runs even when theparityjob it aggregates never ran at all, and fails with nothing to aggregate.How it surfaces
It is normally invisible, because
paritynormally runs. It needs three things at once:run-extended-testslabel, which forcesplan.jobs.parity=true;parityto be skipped rather than run — for example a failingcheck;parity-aggregatethen running anyway, because!cancelled()is true.Observed on PR #10354 with exactly that combination. Fixing the upstream
checkfailure resolves it, so it is not blocking anything — but it means a redparity-aggregatecan be pure noise, pointing at a job that never executed.Fix
Test the dependency's actual result rather than only cancellation:
or whichever result set is intended (
success/skipped). The point is that!cancelled()alone silently opts out of dependency checking, which is rarely what an aggregator wants.Worth auditing the other jobs using a bare
!cancelled()at the same time — the pattern is used elsewhere intest.yml, and each use should be a deliberate choice to run despite a failed dependency rather than an accident.Provenance
Found while triaging CI on PR #10354. The wiring is byte-identical to
main, so this is a latent defect inmainrather than anything that branch introduced.