ci: catch a specification branch moving under a mid-flight SPEC_REF - #23
Merged
Merged
Conversation
During the first order the pin sits at a specification branch's head, where the byte check compares against whatever commit it names and the ancestor check is red throughout — so a commit added to that branch afterwards leaves a vendored file behind with both repositories green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
While
SPEC_REFsits at a specification branch's head — the first order — neither existing check can see that branch move: the byte check compares this tree against whatever commit the pin names, so it stays green against a superseded one, and the ancestor check is red throughout that window by design. A commit added to the branch afterwards leaves a vendored file behind with both repositories green, until the pin moves to the merged commit and the byte check fails on a file nobody was expecting..github/scripts/spec_pin.pyis a third step: it finds the branches holding the pin and fails when a file underschema/,fixtures/ordocs/differs between the pin and one of their heads, naming the files to re-vendor. The signal is a file rather than a moved ref, because a specification branch may gain commits touching only its own prose or its own CI; the step sits before the ancestor check, because a step after a failing one never runs and that one fails for the whole of the window this covers; and it is a no-op once the pin is an ancestor of the specification'smain, which is the resting state.Verified with
pytest— 1052 pass, 16 of them new — and against the specification itself, by cloning it with the branch this was found on put back at the head it reached: the check exits 1 there namingdocs/uddf-mapping.mdand nothing else, exits 0 pinned at the commit whose only successor touches nothing vendored, and exits 0 on the commitSPEC_REFnames today.🤖 Generated with Claude Code