Refuse to tag a VERSION that is not a release version - #42
Merged
Merged
Conversation
reusable-tag-on-release-merge tagged whatever VERSION said, verbatim: any string that is a legal git ref became a tag and a GitHub Release. Versions are named by hand everywhere in this org, so a placeholder sitting in VERSION between releases is the normal state, and a burned tag cannot be reused. audiocomponents mitigated this locally with a validate job; every other consumer is unguarded. The grammar check moves into the reusable, in the step that already reads VERSION, so consumers get it without a local job. It is the same grammar the prepare-release PR and the publish chain accept. tests/test_tag_on_release_merge.py lifts the step's shell out of the YAML and runs it in a throwaway git repository under bash -e, the shell GitHub uses. Closes #32
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.
Fixes #32.
reusable-tag-on-release-merge.ymlrangh release create "v$V"on whateverVERSIONsaid. Any string that is a legal git ref became a tag and a GitHubRelease — including the placeholder a repository carries between releases,
since versions are named by hand here.
audiocomponentsmitigated it with alocal
validatejob; every other consumer is unguarded.The check now lives in the reusable, in the step that already reads
VERSION,so consumers get it without a local job. Same grammar the prepare-release PR
and the publish chain accept:
X.Y.Z[{a|b|rc}N|.devN].How it was proved
The step is shell, so
tests/test_tag_on_release_merge.pylifts therun:body out of the YAML and runs it in a throwaway git repository under
bash -e— the shell GitHub uses — with a real
GITHUB_OUTPUT. It tests the workflow'stext, not a transcription of it.
Refused (exit 1, nothing written to
GITHUB_OUTPUT):0.0.0-PLACEHOLDER-BRAD-NAMES-THIS,v0.2.0,0.2, the empty string,0.2.0-rc1.Accepted (
changed=true,version=set):0.2.0,0.2.0rc1,0.2.0.dev1,1.10.3b2. Two more cover the paths the guard must not disturb: a commit thatdid not touch
VERSION, and a version already tagged.And with the guard removed, to show the fixtures are not passing vacuously:
actionlintclean,ruff check scripts/ tests/clean.Live only at the next
publishing-vNtag. Consumers pin@publishing-v6/@publishing-v8, so nothing changes for them until a new tagis cut, which is not mine to do.
audiocomponentscan drop its localvalidatejob when it moves to that tag; I have left it in place.