feat(tri): ci baseline — which PR gates have never run on the branch they gate (Closes 2309) - #2310
Closed
gHashTag wants to merge 1 commit into
Closed
feat(tri): ci baseline — which PR gates have never run on the branch they gate (Closes 2309)#2310gHashTag wants to merge 1 commit into
gHashTag wants to merge 1 commit into
Conversation
…they gate (Closes 2309) Generalises the emit-bitexact finding: a gate that has never run on the default branch has no green state anyone has ever seen, yet it still turns pull requests red, and a red check nobody else has reads as 'you broke it'. Two wrong answers came first and both are the reason this command reports what it reports. Reading triggers alone flagged 47 workflows because their push: carries a paths: filter -- not a hole; a filtered push still runs on the default branch when those paths change. Counting default-branch runs alone flagged 46 -- also not holes; release, nightly and dispatch-only workflows are supposed to have none and cannot paint a pull request red. The finding is the intersection: PR-gated AND never run on the default branch by any event. Across three repositories that is 4, not 47 and not 46. Three kinds hide in such a list and they need different answers -- a real configuration hole, a gate that is inherently pull-request-scoped, and one whose push: paths simply have not changed yet. Grading them automatically is how a useful sweep turns back into 47 false accusations, so the command prints the taxonomy and leaves the judgement to whoever reads the workflow. The trigger scan is a text scan, not a YAML parse, because 'on:' is a YAML 1.1 boolean: a parser hands back the key true, a lookup of "on" finds nothing in every file, and the sweep reports a clean repository because it read nothing. Its own test caught a missing inline-list spelling.
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
Owner
Author
|
Superseded by #2312: the commit subject here said |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2309. Follow-up to #2276.
Two wrong answers came first, and they are why the command reports what it reports. Reading triggers alone flagged 47 workflows because their
push:carries apaths:filter — not a hole; a filtered push still runs on the default branch when those paths change, which is the sparse baselinetri pr readyalready walks commits to find. Counting default-branch runs alone flagged 46 — also not holes; release pipelines, tag-triggered signing, nightly schedules and dispatch-only builds are supposed to have none and cannot paint a pull request red.The finding is the intersection: PR-gated and never run on the default branch by any event. Across t27, trinity-fpga and zig-golden-float: 4. trinity-fpga (51 active PR gates) and zig-golden-float have zero.
The fourth,
catalog-count-gate.yml, declaredworkflow_dispatch; one dispatch on master gave it a baseline and it left the list.It refuses to grade the survivors, because three different things hide in such a list — a configuration hole (
seal-staleness-warn, whose question is answerable on master and never asked there), one that is inherently pull-request-scoped and correct as it stands (check-now-freshness), and one whosepush:paths simply have not changed on master yet (loop-tools-gate). Grading them automatically is how a useful sweep turns back into 47 false accusations.The trigger scan is a text scan rather than a YAML parse on purpose:
on:is a YAML 1.1 boolean, so a parser returns the keytrue, a lookup of"on"finds nothing in every file, and the sweep reports a clean repository because it read nothing. Its own test caught a missing inline-list spelling (on: [push, pull_request]) before this shipped.🤖 Generated with Claude Code