ci(release): let the floating-tag job run on a dispatch, and say what it covers - #31
Merged
Conversation
… it covers `float-major-tag` could only run on a tag push, so the resume path RELEASING documents — "part-way through the eight crates: re-run release.yml by dispatch" — skipped it. A resumed release therefore finished with `@vN` still pointing at the previous version, which is the exact failure the job was added to prevent. It now runs on a dispatch too, given the tag it is finishing. A dispatch can be handed anything, so the tag is checked to exist and to look like a release tag before a floating pointer is aimed at it. The other half is the ruleset. `protect-release-tags` covered `refs/tags/v*`, which is both kinds of tag, and they want opposite treatment: `v2.0.0` names a published, immutable set of crates, while `v2` is a pointer whose entire contract is to move. Protecting the pointer against being moved is why the job had never once worked — 2.0.0 was its first run, on a creation, and it was rejected outright. Narrowed to `refs/tags/v*.*.*`. Release tags keep every protection they had; the floating majors fall outside, so the job needs no bypass. The alternative — adding the Actions bot to the bypass actors — would have handed the workflow the ability to delete or rewrite a *release* tag, which is a strictly larger permission than the problem needs. RELEASING now documents both, including that 2.0.0's `v2` was pushed by hand, so the next person does not rediscover it. Closes #30. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.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.
Closes #30.
The ruleset half (already applied)
protect-release-tagscoveredrefs/tags/v*— both kinds of tag, which want opposite treatment:v2.0.0v2Protecting the pointer against being moved is why
float-major-taghad never once worked. 2.0.0 was its first run — on a creation, the case only a major bump produces — and it was rejected outright:Narrowed to
refs/tags/v*.*.*. Every existing release tag (v1.0.0 … v2.0.0) keeps creation/update/deletion/non-fast-forward protection;v1andv2fall outside, so the job needs no bypass. Rules, enforcement and the admin bypass are byte-identical — only the condition changed.I chose this over adding the Actions bot to the bypass actors, which would have handed the workflow the ability to delete or rewrite a release tag — a strictly larger permission than the problem needs.
The workflow half (this PR)
float-major-tagwas gated onpush && ref_type == 'tag', so the resume path RELEASING documents — "part-way through the eight crates: re-run release.yml by dispatch" — skipped it. A resumed release finished with@vNstill on the previous version, which is precisely what the job exists to prevent. That hole is independent of the ruleset and would have outlived it.It now runs on dispatch too, given the tag it is finishing. A dispatch can be handed anything, so the tag is checked to exist and to look like a release tag before a floating pointer is aimed at it.
Verification
actionlintclean. I will dispatch it againstv2.0.0after merge — it is idempotent (publish skips what is on the registry, and re-pointingv2at the commit it already names is a no-op), and it is the only way to prove the bot can now move the tag, since I hold the admin bypass myself and my own push proves nothing.Checklist
docs/RELEASING.mdupdated — the dispatch input, and why the ruleset stops where it does