Let the protocol tests run on a branch that declares a version - #166
Merged
Conversation
Tagging 2026.08.1 turned its CI red, and every release branch and tag after it would have gone the same way. The thirteen build jobs pass on that tree; what fails is two tests that assume the repository derives its version, which a release branch is precisely the thing that does not. The version test walks real first-parent history asserting each version precedes the next, and on a release branch every commit answers with the same declared string. It already knows how to say a walk has nothing to walk -- a PR merge ref collapses the range -- so a declared version becomes the second reason. Skipping now leaves the rest of the file running, which matters because the checks below it are about declared versions and were being skipped on the only branches that have one. The monotonicity test builds its own history in a clone and exercises the derived path throughout, so the clone drops VERSION if the branch it came from carries one, rather than assuming none does.
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
1 participant
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.
Tagging
vitasdk-2026.08.1turned its CI red, and every release branch and tag after it would have gone the same way.The thirteen build jobs pass on that tree — the patch builds nine hosts. What fails is two protocol tests, both for the same reason: they assume the repository derives its version, and a release branch is precisely the thing that does not.
The version test walks real first-parent history asserting each version precedes the next under
vercmp. On a release branch every commit answers with the same declared string, so the first comparison it makes is2026.08.1against2026.08.1:It already knows how to say a walk has nothing to walk — a PR merge ref collapses the range to one commit — so a declared version becomes the second reason for the same skip. The skip no longer
exit 0s: the checks below it are about declared versions, and they were being skipped on exactly the branches that have one.The monotonicity test starts by committing a clock-skewed revision and expecting
describeto refuse it. That guard only runs on the derived path:so on a release branch
describetakes the declared path, never checks the date, and the test sees a success where it wanted a refusal. It builds its own history in a clone and exercises the derived path throughout, so the clone now dropsVERSIONif the branch it came from carries one.Neither change touches
describe. The date check has nothing to say about a version a person typed, and the declared path is guarded by the previous-version gate instead.Verified both ways: six of six on
master, and six of six onnext-patch-2026.08.1, where the skip says which revision declared a version rather than passing silently.AI tools were used in preparing this PR (Claude Opus 5, Anthropic).