fix(release): the tag check refused every tag for not following itself - #10
Merged
Conversation
v0.2.0 was tagged and both publishing workflows stopped at the same step: v0.2.0 does not come after v0.2.0, the highest release tag there is. The lookup that finds the previous release asked git for every `v*` tag and took the highest. In CI on a tag push the tag being checked HAS ALREADY BEEN CREATED — that push is what started the run — so it was always its own predecessor. Nothing published; both workflows refused before doing anything, which is at least the failure mode a pre-flight check should have. It passed locally because the tag did not exist yet when it was run there, which is the same reason none of the seventeen cases in the suite saw it: every one passed the previous tag explicitly, so not one of them used the lookup. So the suite now stages a repository — the script, a dune-project, real tags — and asks the question CI asks in the state CI asks it in. Reverting the fix turns that case red. The exclusion gives up one thing: it can no longer tell that a version was already released. That case is unreachable from CI regardless, since the tag is always present there, so the choice was never "catch it" — it was "refuse everything", and a check that refuses everything gets deleted. Co-Authored-By: Claude Opus 5 (1M context) <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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Cutting
v0.2.0stopped both publishing workflows at the same step:The lookup that finds the previous release asked git for every
v*tag and took the highest. In CI on a tag push the tag being checked has already been created — that push is what started the run — so every tag was its own predecessor and every release was refused. Nothing was published; both workflows stopped before doing anything, which is at least the failure mode a pre-flight check should have.It passed locally because the tag did not exist yet when it was run there. And that is the same reason none of the seventeen cases in the suite saw it: every one passed the previous tag explicitly, so not one of them used the lookup. The suite now stages a repository — the script, a
dune-project, real tags — and asks the question CI asks, in the state CI asks it in. Reverting the fix turns that case red (checked, not assumed).The exclusion gives up one thing: the check can no longer tell that a version was already released. That case is unreachable from CI regardless, since the tag is always present there — so the choice was never "catch it", it was "refuse everything".
🤖 Generated with Claude Code