Add a Release workflow, and stop moving v0 - #3
Merged
Conversation
Releasing was a `git tag` by hand with the moving `v0` repointed by hand beside it -- two commands nothing checked, where forgetting the second silently left all sixteen consumers on the previous version. It is a button now: workflow_dispatch with a patch/minor/major choice, which re-runs CI against the commit, computes the next version from the tag history, refuses to overwrite an existing tag, and publishes. CI gained `workflow_call` so Release runs exactly those checks rather than a copy. A reusable WORKFLOW rather than a composite action because the install job is a matrix over two operating systems, and a matrix belongs to a job -- a composite cannot own one, so reusing it that way would have meant rewriting the matrix in the caller and letting the two drift. Deliberately NOT copied from the sibling komizo-actions: the pin- rewriting release script. That exists there because its `deploy` action composes five siblings and GitHub resolves each inner `uses:` independently of the caller's ref, so a consumer's SHA pin covers one file and leaves five floating. Neither action here composes a sibling -- the only mention of gdam-actions inside one is an error message -- so there is nothing to rewrite, and a copy of that script would be ceremony guarding a problem this repository does not have. The README recommended tracking `@v0` because "a fix reaches every repository without 17 pull requests". That is true and it is also the whole risk: a bad release reaches them just as fast, with no way to stay on the previous one short of finding its SHA, and nothing in a consumer's workflow recording which files it actually ran. Seventeen pull requests is the price of knowing. 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 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.
Gives this repo the same release story as komizo-actions — immutable versions, cut by a workflow instead of by hand.
What changes
.github/workflows/release.yml—workflow_dispatchwithpatch/minor/major. Re-runs CI against the commit, computes the next version from the tag history, refuses to overwrite an existing tag, then publishes.ci.ymlgainsworkflow_callso Release runs exactly those checks rather than a copy.@v0.Two places I did not copy komizo-actions
No pin-rewriting release script. That machinery exists there because
deploycomposes five sibling actions, and GitHub resolves each inneruses:independently of the caller's ref — so a consumer's SHA pin covers one file and leaves five floating. Neither action here composes a sibling (the only mention ofgdam-actionsinside one is an error message), so there is nothing to rewrite. A copy of that script would be ceremony guarding a problem this repo doesn't have.Reusable workflow, not a composite action. komizo-actions shares its checks via
.github/actions/check. That doesn't work here: theinstalljob is a matrix overubuntu-latestandmacos-latest, and a matrix belongs to a job — a composite action can't own one, so reusing it that way would mean rewriting the matrix in the caller and letting the two drift.workflow_callkeeps one definition.On the version number
The next release is
v0.1.2, notv0.0.1. This repo already hasv0.1.0andv0.1.1, andv0.0.1would sort below both:So a
v0.0.1here would be a release that every version-ordering tool considers older than what's already out.patchoffv0.1.1is the right bump, and the README examples say@v0.1.2in anticipation.On
@v0The README argued for it honestly — "a fix reaches every repository without 17 pull requests". That's true, and it's also exactly the risk: a bad release reaches them just as fast, with no way to stay on the previous one short of finding its SHA by hand, and nothing in a consumer's workflow recording which files it actually ran.
v0currently points at the same commit asv0.1.1, so nothing is broken today. Once the 16 consumers are moved ontov0.1.2it should be deleted, so@v0fails loudly rather than silently serving whatever it last pointed at.