chore: move releases onto release-plz like the sibling crates - #11
Merged
Conversation
This was the last repository still driving releases by hand: tag the commit, dispatch Release with the tag and a publish checkbox, approve. It worked, but it left the version bump, the changelog entry, and the tag as three manual steps that nothing checked against each other, and it was the only one of the four crates not on the pattern. release-plz.yml now runs on every push to main and publishes only when the manifest version is ahead of the registry, so merging a reviewed release pull request is what authorises a publish. Two deviations from the upstream template stay, both documented upstream: a GitHub App token, because the default GITHUB_TOKEN cannot trigger the CI a release pull request needs, and windows runners, because cargo publish verifies the tarball by building it and this crate does not build on Linux. release.yml becomes release-finalize.yml, called from the same run. git_release_enable = false leaves the GitHub release to it, so the existing draft-release xtask still applies the crate, both SBOMs, and checksums before anything is published. It cannot be a release-event handler: GitHub fires no release events for drafts. The finalizer gains a check the manual flow could not make. It previously attested an archive it had just built, with no evidence that archive was what the registry served. It now requires the rebuilt archive's SHA-256 to equal the published crate before attesting, so the provenance is bound to the artifact consumers actually download. crates-io-auth-mode is kept and reused rather than reimplemented in the workflow: it is already tested, and duplicating the check in YAML would have left the xtask dead. Co-Authored-By: Claude Fable 5 <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.
The last repository still releasing by hand.
windows-spawnhad no release-plz at all: you tagged a commit, dispatched Release with the tag and a publish checkbox, and approved. That worked — 0.1.0 shipped through it — but the version bump, the changelog entry, and the tag were three manual steps nothing checked against each other.What changes
release-plz.ymlruns on every push tomainand publishes only when the manifest version is ahead of the registry, so an unrelated merge cannot release. Merging a reviewed release pull request is what authorises a publish.Two deviations from the upstream template stay, both documented upstream:
GITHUB_TOKENcannot trigger other workflows, so CI would never run on a release pull request.cargo publishverifies the tarball by building it, and this crate does not build on Linux — itswindows-sysdependency sits behindcfg(windows)while the modules using it do not.conpty-oxidefailed a release on exactly this after adopting the template'subuntu-latest.release.ymlbecomesrelease-finalize.yml, called from the same run withneeds: release.git_release_enable = falseleaves the GitHub release to it, so the existingdraft-releasextask still applies and the crate, both SBOMs, and checksums are attached before anything is published. It cannot be a release-event handler — GitHub fires no release events for drafts.One thing the manual flow could not do
The finalizer previously attested an archive it had just built, with nothing establishing that archive was what crates.io served. Because release-plz now publishes first, the finalizer can compare: it requires the rebuilt archive's SHA-256 to equal the published crate before attesting. The provenance is now bound to the artifact consumers actually download.
crates-io-auth-modeis kept and reused rather than reimplemented in YAML — it is already tested, and duplicating the check would have left the xtask dead.Configuration this needs
Before merging, the
releaseenvironment needs:RELEASE_PLZ_APP_CLIENT_ID(variable) andRELEASE_PLZ_APP_PRIVATE_KEY(secret) for the installedp4suta-release-plzApp, matching the sibling repositories. The App must be installed on this repository.CRATES_IO_BOOTSTRAP_TOKENcan stay until a trusted publisher is registered for.github/workflows/release-plz.yml+ thereleaseenvironment, then be deleted.Note the environment currently has a required reviewer. With
on: push, that makes every merge tomainwait for a deployment approval, not just releases. The sibling repositories carry a branch policy without a reviewer gate and rely on the release pull request as the approval point. Removing the reviewer rule here would match them; keeping it means an approval click per merge.Verification
just cipasses end to end: fmt, clippy, tests, doc, MSRV 1.75, three windows targets plus linux, cargo-deny, REUSE, typos, public-api snapshot, andcargo package+ verify.actionlintpasses on both new workflows.🤖 Generated with Claude Code