Repository navigation
ci: add release-v3 PR-based release workflow (release-please) - #88
Merged
Merged
Conversation
release-v3 replaces the direct-to-main release model of release-v2. Instead of semantic-release pushing the version bump + CHANGELOG to main (which requires the App to bypass branch protection), v3 opens a release PR for human review. Phase A (normal push to main): compute the next version via semantic-release --dry-run, close any stale open release PR (label: autorelease) and delete its branch, recreate the bump + CHANGELOG on an autorelease/v<version> branch reusing the repo's own prepareCmd, and open a fresh release PR. Phase B (release PR merged): create the tag + GitHub Release, triggering the repo's existing release:published publish workflows. The App token only pushes to autorelease/* branches and manages PRs — it never commits to main — so the App can be removed from the main-branch ruleset bypass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Harden the App token handling in release-v3: - Scope the minted token to this repository (create-github-app-token default) and to the minimum permissions (contents + pull-requests write) via permission-* inputs. - Mint the token only after all repository/dependency code (semantic-release, cargo, npm) has run, and expose it solely to the git-push / PR / release steps. - Run the version compute (dry-run) under the default GITHUB_TOKEN, and the bump under no token at all. - checkout with persist-credentials: false so no token is left on disk during a build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace the semantic-release + hand-rolled prepare/publish glue with a thin release-please wrapper. release-please natively opens and maintains the release PR, bumps Cargo.toml + Cargo.lock (via the cargo-workspace plugin) and the CHANGELOG, and on merge creates the tag + GitHub Release that triggers the existing publish workflows. It edits manifests directly (no cargo/npm build), so no repository code runs during a release and the App token is never exposed to a build script. The token is repo-scoped and limited to contents + pull-requests + issues write. Each consumer supplies release-please-config.json and .release-please-manifest.json. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
kayibal
changed the title
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.
Reusable release workflow that opens a release PR for human review instead of pushing the version bump to main. Built on
release-please.Behaviour
release-please handles both phases in one run (triggered by the caller's push to main):
Cargo.toml/Cargo.lock+ CHANGELOG, from Conventional Commits)release: publishedpublish workflows (crates.io, npm, binaries, images)Why release-please over semantic-release
release-v2pushes the release commit straight to main via@semantic-release/git, which requires the App to bypass the main-branch ruleset. Forcing semantic-release into a PR model needs fragile glue (dry-run parsing, config extraction, hand-rolled tag creation). release-please is built for the PR model: it maintains the PR natively, keeps it updated as commits land, and only tags on merge.Token handling
contents+pull-requests+issueswrite.cargo/npmbuild runs, so no dependencybuild.rs/install script executes during a release and the token is never exposed to one.GITHUB_TOKEN) is required so the release PR gets CI and the published release triggers downstream workflows.Requires
issues: writeadded (currently missing) for release-please label management.release-please-config.json+.release-please-manifest.json(replacingrelease.config.js), usingrelease-type: rust+ thecargo-workspaceplugin (updatesCargo.lock) andinclude-v-in-tags: false(keeps bare version tags).Behavioural deltas vs semantic-release (agreed)
refactor/security/stylecommits no longer trigger a release on their own (onlyfeat/fix/breaking do).feat!:/BREAKING CHANGE:rather than abreaking:type.Not yet exercised end-to-end;
token-quoteris the planned first cutover / validation.🤖 Generated with Claude Code