ci: auto-cut a release when a new CHANGELOG version lands on main#9
Merged
Conversation
Make release.yml callable via workflow_call (a required 'tag' input) in addition to its tag-push trigger, and add auto-release.yml which, on a push to main, tags the newest un-released CHANGELOG version and invokes release.yml to build and publish it — no PAT, using the built-in token (a GITHUB_TOKEN-pushed tag would not trigger the tag event, so release.yml is called explicitly instead). release.yml's security posture is preserved: both jobs still check out github.sha (never the tag name), persist-credentials stays false, the no-branch-push tripwire and check-plan-shipped/attestation/prune gates are unchanged; the derived TAG is only ever a name (version stamp, release title, prune), never a checkout ref. auto-release tags only the NEWEST version (tagging the backlog at HEAD would mis-point immutable tags at the wrong code), is idempotent (no-op if that version is already tagged), and floors permissions at contents: read, escalating only the tag job to contents: write and granting the release call exactly the write scopes release.yml needs. Security-reviewed: PASS (anti-tag-move, tripwire, permission capping, injection, token, fail-closed attestation, idempotency all verified).
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.
Auto-cut a release when a new CHANGELOG version lands on
mainImplements release automation the reusable-workflow way (no PAT).
How it works
release.ymlbecomes callable (workflow_call+ a requiredtaginput) alongside its existing tag-push trigger.auto-release.yml(on: push: main): detect the newest dated CHANGELOG version → if it has no tag, tag it atgithub.sha(built-in token) → release by callingrelease.yml(uses: ./.github/workflows/release.yml). Calling it explicitly sidesteps GitHub's "aGITHUB_TOKEN-pushed tag doesn't trigger a workflow" rule — so no PAT, no standing credential.Security (reviewed — PASS)
Every
release.ymlinvariant is preserved: both jobs still check outgithub.sha, never the tag name (anti-tag-move);persist-credentials: false; the record-and-assert-remote-tip-unchanged tripwire;check-plan-shipped, build-provenance attestation (+ fail-closed verify — ferry is public), and prune. The derivedTAGis only ever a name (version stamp / release title / prune), never a checkout ref.auto-releasefloors atcontents: read, escalates only the tag job tocontents: write(pushes a newvX.Y.Zonly — can't move a tag or push a branch), and the version is regex-bounded to digits/dots (no injection). Idempotent: a no-op if the newest version is already tagged.On merge (a push to
main), the workflow sees the newest CHANGELOG version0.7.3untagged → tagsv0.7.3at HEAD →release.ymlbuilds the four binaries +checksums.txt+ provenance and publishes a public GitHub Release. That's the intended first cut. Every future CHANGELOG-bumping merge then releases hands-free.Backlog note (by design)
v0.7.0–v0.7.2stay untagged — auto-release only ever tags the newest version, because tagging older versions at the current HEAD would permanently mis-point immutable tags at v0.7.3's code. They were same-day dev milestones superseded onmain. If you want their tags for history, I can create them at their real merge commits as a one-time manual step.Known operational limit (not a regression)
If a release run fails verification, the tag is already pushed and that version won't auto-retry — delete the remote tag to retry. This mirrors ferry's existing manual tag-push model.
Assisted-by: Claude:claude-opus-4-8