ci(release): move the floating vN tag on publish - #12
Merged
Conversation
The README tells users to write `vyncint/launchbound/action@v1`, which makes that tag the contract for everyone who followed the documentation. Moving it was a manual step, and a manual step in a release is a step that gets skipped: v1 sat on 1.0.2 through both 1.1.0 and 1.2.0. The effect was not cosmetic. The only thing that changed in the action between 1.0.2 and 1.2.0 is the default reconverge-version, 0.1.11 to 0.3.0 -- so every consumer on the documented ref, including the demo repository that exists to exercise this action, kept gating with the old analyzer while 1.2.0's entire subject was moving that pin. Runs after a successful publish only, and only on a tag push, so the floating tag can never point at a release that did not reach crates.io. The workflow's trigger requires three numeric components, so pushing v1 cannot re-enter it. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com>
Each tool has a repository that exercises it against a real subject, and each of those resolves "latest" from crates.io on a schedule of its own -- so a new version is picked up without anything being edited, but only at the next tick. That is up to a day for the daily checks and up to a week for the weekly ones. A repository_dispatch on publish starts the deep run immediately. It is best-effort on purpose: continue-on-error, and a missing token is a notice rather than a failure. The schedules stay exactly as they were, because a dispatch that never arrives -- an expired token, a release cut by hand, a fork without the secret -- must cost latency and nothing else. A published crate is published whether or not the notification landed. Needs a PAT with contents: write on the testing repository, stored as TESTING_REPO_DISPATCH_TOKEN. Without it the job says so and exits clean. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com>
zizmor audits at pedantic level, where a job without a `name:` is an anonymous-definition finding. 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
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.
v1has been sitting on 1.0.2 through both 1.1.0 and 1.2.0.The README tells users to write
vyncint/launchbound/action@v1, so that tag is the contract for everyone who followed the documentation. Moving it was a manual step, and a manual step in a release is a step that gets skipped.The effect was not cosmetic. The only difference in the action between 1.0.2 and 1.2.0 is the default
reconverge-version:So every consumer on the documented ref — including
vyncint/launchbound-action-demo, which exists to exercise this action — has been gating with reconverge 0.1.11, while pinning 0.3.0 was 1.2.0's entire subject. And reconverge's behaviour did move across that range:vyncint/simt-diffhas recorded four corpus entries changing fromwarningtoconfirmedsince 0.1.6.The fix
A
float-major-tagjob that runs after a successful publish and only on a tag push, so the floating tag can never point at a release that did not reach crates.io. The workflow's trigger requires three numeric components (v[0-9]*.[0-9]*.[0-9]*), so pushingv1cannot re-enter the workflow.Derivation checked for
v1.2.0 → v1,v10.3.1 → v10,v2.0.0-rc1 → v2.v1still needs moving once by hand for the releases that already shipped; this only prevents the next one.Caught by
A new drift check in
launchbound-action-demothat comparesaction/action.ymlat@v1against the newest release tag — the one question the demo could not ask, because it uses@v1on purpose (a demo should exercise what users copy).