ci: release only from a signed tag and an approved deployment - #27
Merged
Merged
Conversation
release-plz now only keeps a draft release pull request; it never tags and never publishes. The maintainer's signed `vX.Y.Z` tag starts release.yml, which verifies that the tag names a commit on main whose Cargo version it matches, and attests the release candidate. Publishing waits in the `crates-io` environment for the maintainer's approval, then takes a crates.io token through trusted publishing alone. It publishes only if `cargo package` makes the attested archive, and then requires crates.io to serve it. The GitHub release follows, as release-finalize.yml did. 0.1.0 went out with a bootstrap token, so `crates-io-auth-mode` and its fallback go. The `release` environment now serves only the release pull request, from main.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
release.yml runs as the tagged commit has it, so this check is defence in depth: the creation rule and the approval remain the gates, and the approver now checks the run before approving. The tag protection is described as two rulesets, because a bypass actor skips every rule of its ruleset, signatures and the ban on moving tags included. actions/attest moves to v4.2.2, which `v4` now names.
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.
Releases now follow the shape OComment uses: a machine proposes, and the maintainer signs and approves.
release-plz.ymlonly keeps a draft release pull request, bumping the version and updatingCHANGELOG.md; it never tags and never publishes.vX.Y.Ztag starts the newrelease.yml:candidaterequires an annotated tag GitHub verified as signed, verifies that it names a commit onmainwhose Cargo version it matches, builds the reproducible release candidate, and attests SLSA v1 provenance and the CycloneDX SBOM.publishwaits in thecrates-ioenvironment for the maintainer's approval, and takes a crates.io token through trusted publishing only.It publishes only if
cargo packagemakes the attested archive, and then requires crates.io to serve that archive.github-releaseattaches the crate, SBOMs, and checksums to a draft release and publishes it, asrelease-finalize.ymldid.cargo xtask crates-io-auth-modeand the bootstrap-token fallback go: 0.1.0 is out, so trusted publishing is the only credential.docs/releasing.mddescribes the new flow.Settings this needs
Already done:
crates-ioenvironment: the maintainer is its required reviewer, and it deploys fromv*tags only;releaseenvironment deploys frommainonly;crates-io.Left for the maintainer:
P4suta/windows-spawn, workflowrelease.yml, environmentcrates-io, with trusted publishing required;CRATES_IO_BOOTSTRAP_TOKENsecret;v*tag rulesets, because a bypass actor skips every rule of its ruleset: one where only the maintainer may bypasscreation, and one withupdate,deletionandrequired_signaturesthat nobody bypasses.Verification
actionlintandzizmorreport nothing on either workflow.cargo xtask gates, the xtask tests,typosandreuse lintpass.