#161's measured work is good and should return. It was reverted in #166 only because it took the whole fleet's CI down for 18 minutes.
What happened
d68fb727 made quality.yml unresolvable to GitHub. Every code-quality run created between 13:29:41Z and 13:47:44Z startup-failed with zero jobs, in every repo, including branches with no changes under .github/.
It reports conclusion: failure, so it reads as an ordinary red. Two discriminators:
- the run's
name is the raw path .github/workflows/code-quality.yml instead of Code Quality — GitHub never resolved the workflow, so it never learned its name;
- jobs = 0.
Same repo, callers untouched: 13:22:46Z → 28 jobs; 13:33:34Z → 0 jobs. After #166: 21 jobs.
What is NOT the cause
The file parses cleanly, including under a strict loader with duplicate-key detection (GitHub rejects duplicate keys; yaml.safe_load silently keeps the last, so a plain parse proves nothing). The rejection is above YAML syntax.
Candidates, neither proven
workflow_call inputs went 43 → 45- file size went 207,576 → 224,420 bytes
Both are testable on a branch with a throwaway caller: add inputs one at a time until a run's name stops resolving. Please bisect rather than guess — that is what could not be done during the outage.
Two asks beyond the re-land
A startup-failure canary. Nothing in the fleet distinguishes "the gate failed" from "there was no gate". A permanent per-run check that asserts the run resolved — job count non-zero, name != the raw path — would have caught this in one run rather than after four repos had been misdiagnosed. Same family as the positive control added in #148.
Trim the input descriptions. Several are multi-paragraph essays; the longest is 1,387 characters. That belongs in a doc the descriptions link to. If size is the cause, this is also the fix; if it isn't, it still removes the suspicion for next time.
Refs #155, #161, #166.
#161's measured work is good and should return. It was reverted in #166 only because it took the whole fleet's CI down for 18 minutes.
What happened
d68fb727madequality.ymlunresolvable to GitHub. Everycode-qualityrun created between 13:29:41Z and 13:47:44Z startup-failed with zero jobs, in every repo, including branches with no changes under.github/.It reports
conclusion: failure, so it reads as an ordinary red. Two discriminators:nameis the raw path.github/workflows/code-quality.ymlinstead ofCode Quality— GitHub never resolved the workflow, so it never learned its name;Same repo, callers untouched: 13:22:46Z → 28 jobs; 13:33:34Z → 0 jobs. After #166: 21 jobs.
What is NOT the cause
The file parses cleanly, including under a strict loader with duplicate-key detection (GitHub rejects duplicate keys;
yaml.safe_loadsilently keeps the last, so a plain parse proves nothing). The rejection is above YAML syntax.Candidates, neither proven
workflow_callinputs went 43 → 45Both are testable on a branch with a throwaway caller: add inputs one at a time until a run's
namestops resolving. Please bisect rather than guess — that is what could not be done during the outage.Two asks beyond the re-land
A startup-failure canary. Nothing in the fleet distinguishes "the gate failed" from "there was no gate". A permanent per-run check that asserts the run resolved — job count non-zero,
name!= the raw path — would have caught this in one run rather than after four repos had been misdiagnosed. Same family as the positive control added in #148.Trim the input descriptions. Several are multi-paragraph essays; the longest is 1,387 characters. That belongs in a doc the descriptions link to. If size is the cause, this is also the fix; if it isn't, it still removes the suspicion for next time.
Refs #155, #161, #166.