chore: migrate release process from semantic-release to release-please - #255
Conversation
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HgsnnsDi5ksjBJd5NvLYpB
|
Warning Review limit reached
Next review available in: 43 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR migrates the release process from semantic-release (dev-release.yml, release.yml, release.config.mjs) to Google's release-please. It adds a new release-please.yml workflow with config/manifest files for main and beta branches, updates docker-build.yml's secrets interface and tag-validation regex, and updates CI/GitLab comments and documentation accordingly. ChangesRelease-please migration
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release-please.yml:
- Around line 32-35: The workflow-level permissions in release-please.yml are
too broad and currently apply to both jobs; move the `contents`,
`pull-requests`, and `issues` write permissions into the `release-please` job so
only that job has them, and keep the `docker` job at minimal permissions (or
none) since it only calls `docker-build.yml`. Use the `release-please` and
`docker` job definitions to relocate the permissions without changing the job
behavior.
In `@CLAUDE.md`:
- Around line 118-121: Clarify the beta release format in the release-please
documentation by stating that prerelease tags use the full `v<x.y.z>-beta.<n>`
pattern, not just `-beta`. Update the mirrored release-process guidance in the
sections describing `release-please`, the `beta` branch, and `prerelease-type:
beta` so all docs consistently reflect the actual tagging behavior and workflow
contract.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1059d03d-735d-481b-8669-ea76dd3e2048
📒 Files selected for processing (17)
.github/workflows/ci.yml.github/workflows/dev-release.yml.github/workflows/docker-build.yml.github/workflows/release-please.yml.github/workflows/release.yml.github/workflows/secrets-scan.yml.gitlab-ci.yml.release-please-manifest.beta.json.release-please-manifest.jsonCLAUDE.mdCONTRIBUTING.mddocs/build/contributing.mddocs/build/conventions.mdeslint.config.mjsrelease-please-config.beta.jsonrelease-please-config.jsonrelease.config.mjs
💤 Files with no reviewable changes (4)
- .github/workflows/release.yml
- .github/workflows/dev-release.yml
- release.config.mjs
- eslint.config.mjs
Grants security-events:write + id-token:write to the docker job (Trivy SARIF upload + Sigstore) which the workflow-level block had dropped vs the retired release.yml, and confines the release-please write scopes to that job. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HgsnnsDi5ksjBJd5NvLYpB
1 participant
What changed
Replaces semantic-release v25 with release-please as the release engine. Deleted
release.config.mjs,.github/workflows/release.yml, and.github/workflows/dev-release.yml; added.github/workflows/release-please.ymlplus two config/manifest pairs (release-please-config.json+.release-please-manifest.jsonformain, and the.beta.jsonvariants for a newbetabranch).Why
semantic-release's per-branch dev-prerelease rail (a prerelease cut from every non-main push) added noise without much value, and its config/plugin surface (
release.config.mjs) was another thing to keep patched. release-please is PR-based: it maintains a standing "Release PR" that accumulates the changelog, and cutting a release is just merging that PR, no separate release commit step, no local semantic-release invocation.New release flow
flowchart LR DEV["Feature branch<br/>PR merged"]:::keep --> MAIN["main branch"]:::keep DEV --> BETA["beta branch"]:::keep MAIN --> RPMAIN["release-please.yml<br/>config: release-please-config.json"]:::proc BETA --> RPBETA["release-please.yml<br/>config: release-please-config.beta.json"]:::proc RPMAIN --> PRMAIN["Release PR<br/>vX.Y.Z + CHANGELOG"]:::pr RPBETA --> PRBETA["Release PR<br/>vX.Y.Z-beta + CHANGELOG"]:::pr PRMAIN -- merge --> RELMAIN["GitHub release<br/>tag vX.Y.Z"]:::rel PRBETA -- merge --> RELBETA["GitHub release<br/>tag vX.Y.Z-beta"]:::rel RELMAIN --> DOCKERMAIN["docker-build.yml<br/>prod image + latest"]:::img RELBETA --> DOCKERBETA["docker-build.yml<br/>beta image, no latest"]:::img classDef keep fill:#2c3e50,color:#ffffff classDef proc fill:#34495e,color:#ffffff classDef pr fill:#8e44ad,color:#ffffff classDef rel fill:#27ae60,color:#ffffff classDef img fill:#ecf0f1,color:#2c3e50main: stable channel. Merging the Release PR cutsv<x.y.z>, updatesCHANGELOG.md+package.json, creates a GitHub release, and builds/pushes the prod image tagged:latest.beta: prerelease channel (versioning-strategy: prerelease+prerelease: true+prerelease-type: beta). Merging its Release PR cutsv<x.y.z>-betaand builds a beta image, no:latest.release-please.ymlselects the right pair at runtime viagithub.ref_namesomainandbetastate never mixes.docker-build.yml's tag-validation regex was widened to accept the beta suffix format, and itssecrets:block was tightened fromsecrets: inheritto explicitDOCKER_USERNAME/DOCKER_PASSWORDso theRELEASE_TOKENPAT used byrelease-please.ymlis never forwarded into the image-build graph.Preservation guarantees
CHANGELOG.mdis not rewritten, release-please prepends new sections the same way semantic-release did.v1.14.0tag is auto-detected by release-please for changelog/version continuity (manifests seeded to1.14.0).include-component-in-tag: falsekeeps the existingv<version>tag scheme, matching both the current tags anddocker-build.yml's tag regex. (In manifest mode this option defaults totrue, which would have producedgithub-app-v1.15.0and broken continuity + the docker build, so it is set explicitly.)Fidelity note
Only
feat,fix, and breaking (!) commits bump the version now. Under the old semantic-release ruleset,refactor/perf/revertalone could also cut a release; release-please's default Conventional Commits mapping does not treat those as release-triggering by themselves. The old per-feature-branch dev-prerelease rail is retired entirely in favor of the singlebetabranch channel.Other changes
docs/build/conventions.md,docs/build/contributing.md,CLAUDE.md,CONTRIBUTING.md: updated to describe the release-please flow..gitlab-ci.yml: removed the already-disabled, commented-outsemantic-releasejob; left a pointer comment that GitHub (via release-please) is now the single source of releases.eslint.config.mjs: dropped now-dead ignore entries forrelease.config.mjs/release.config.dev.mjs..github/workflows/ci.yml/secrets-scan.yml: comment-only updates reflecting the new release trigger.Reviewer notes / follow-ups
mainandbetamust require theci.ymlPR checks. Unlike the old pipeline,release-please.ymldoes not itself invokeci.yml: the Release PR is gated purely by branch-protection-required status checks, anddocker-build.ymlonly runs post-merge whenrelease_created == true.betabranch does not exist yet, it must be created offmainafter this PR merges before the beta release channel can produce its first Release PR.RELEASE_TOKEN(a PAT, not the defaultGITHUB_TOKEN) must be present as a repo secret so the Release PR itself can trigger downstream required-checks workflows.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
Documentation