Repository navigation
ci(release): automate releases with release-please - #1490
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
📝 WalkthroughWalkthroughAdds ChangesRelease-please configuration
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Failed to generate code suggestions for PR |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
No issues found across 4 files
Auto-approved: Adds release-please configuration and workflow for automated releases, removes old release workflow. CI/CD changes only, no logic or production code changes.
Re-trigger cubic
706b351
|
Good catch — fixed in 706b351. Releases published by the default |
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
There was a problem hiding this comment.
0 issues found across 1 file (changes from recent commits).
Requires human review: Adds release automation and removes old workflow; CI/CD and deployment pipeline changes are high-impact and require human review.
Re-trigger cubic
Implements the accepted ADR (decisions/2026-06-16-release-cadence-automate-releases.md): release-please maintains a single open release PR on every main push, pre-computing the next semver bump + CHANGELOG from conventional commits. Merging that PR tags v* and publishes a GitHub Release, whose release:published event triggers the unchanged deploy.yml gate. - Add release-please-config.json (node release-type, root package, tag without component prefix so it stays v2.18.0). - Seed .release-please-manifest.json at 2.17.0 → first managed release is 2.18.0, not a reset. - Add .github/workflows/release-please.yml (push:main, no auto-merge — the one-click merge is the deliberate ship-to-prod checkpoint). - Retire release.yml: it created a GitHub Release on v* tag push, which release-please now does on release-PR merge; leaving it would double-create. Its build+test gate is already covered by Quality Gates. Refs #1478
Releases created with the default GITHUB_TOKEN do not raise events that trigger other workflows (GitHub's recursion guard), so the release: published event would fire but deploy.yml would never run — silently breaking the prod deploy chain. Switch release-please to a PAT (RELEASE_PLEASE_TOKEN, contents RW + pull-requests RW) so the published release propagates to deploy.yml. The PAT also creates the release PR without needing the 'Allow Actions to create PRs' repo setting.
706b351 to
3630da1
Compare
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release-please.yml (1)
16-18: ⚡ Quick winReduce default
GITHUB_TOKENto least privilege.Line 16–18 grants write on the default token, but this job authenticates release operations with
secrets.RELEASE_PLEASE_TOKEN(Line 38). Tightening these to read-only reduces blast radius if a step/action is compromised.Suggested hardening diff
permissions: - contents: write - pull-requests: write + contents: read + pull-requests: read🤖 Prompt for 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. In @.github/workflows/release-please.yml around lines 16 - 18, The permissions block at lines 16-18 grants write access to contents and pull-requests for the default GITHUB_TOKEN, but since this workflow authenticates release operations using secrets.RELEASE_PLEASE_TOKEN instead, the default token should be restricted to follow the least privilege principle. Change the permissions for both contents and pull-requests from write to read to minimize the blast radius if a step or action becomes compromised.
🤖 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.
Nitpick comments:
In @.github/workflows/release-please.yml:
- Around line 16-18: The permissions block at lines 16-18 grants write access to
contents and pull-requests for the default GITHUB_TOKEN, but since this workflow
authenticates release operations using secrets.RELEASE_PLEASE_TOKEN instead, the
default token should be restricted to follow the least privilege principle.
Change the permissions for both contents and pull-requests from write to read to
minimize the blast radius if a step or action becomes compromised.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: dfd89410-02bf-44fd-9e61-22277cb25dea
📒 Files selected for processing (4)
.github/workflows/release-please.yml.github/workflows/release.yml.release-please-manifest.jsonrelease-please-config.json
💤 Files with no reviewable changes (1)
- .github/workflows/release.yml
✅ Files skipped from review due to trivial changes (2)
- .release-please-manifest.json
- release-please-config.json
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
- GitHub Check: Test — frontend
- GitHub Check: Test — backend
- GitHub Check: Test — shared
- GitHub Check: Test — bot
- GitHub Check: Checks
- GitHub Check: Vercel Agent Review
- GitHub Check: danger / danger
- GitHub Check: quality / Dead code (knip)
- GitHub Check: quality / Lint (lint)
- GitHub Check: quality / SAST (CodeQL) (javascript-typescript)
- GitHub Check: Build — frontend
- GitHub Check: Build — backend
- GitHub Check: Security
|
This branch was successfully deployed
1 participant
What
Implements the accepted ADR
decisions/2026-06-16-release-cadence-automate-releases.md(#1478) — never actually built until now (no config/manifest/workflow existed on disk).release-please maintains one open release PR on every push to
main, pre-computing the next semver bump + CHANGELOG from conventional commits. Merging that PR tagsv*and publishes a GitHub Release, whoserelease: publishedevent triggers the unchangeddeploy.ymlgate (30-min bake → homelab webhook → migrations → auto-rollback).Why now
git rev-list --count v2.17.0..main= 145 commits stranded undeployed since v2.17.0 (2026-06-08) — incl. prod-breaking/download+/helpfixes, security fixes (#1457 vite/form-data HIGH, #1283 CSP), and incident fixes (#1469, #1472). Releases were still fully manual and stalled — the exact failure the ADR was written to stop.Changes
release-please-config.json—noderelease-type, root packagelucky-bot,include-component-in-tag: falseso the tag staysv2.18.0(whatdeploy.ymlexpects)..release-please-manifest.json— seeded at2.17.0→ first managed release is 2.18.0, not a reset..github/workflows/release-please.yml—push: main, action pinned to a commit SHA (repo convention), no auto-merge (the one-click merge is the deliberate ship-to-prod checkpoint, per ADR + chore(deploy): rapid successive merges cause false-failure in 'Validate deployed version' #1397).release.yml— it created a Release onv*tag push; release-please does that on release-PR merge, so leaving it would double-create. Confirmed no other workflow triggers onv*. Its build+test gate is already covered by Quality Gates on main.Deploy chain verified
deploy.ymltriggers onrelease: published(+workflow_dispatch) — intact.docker-publish.ymlbuilds:<sha>images on everymainpush — images exist for the release-PR-merge SHA.workflow_dispatch-by-SHA fast-path unchanged.release-please uses
secrets.RELEASE_PLEASE_TOKEN(a PAT), NOT the defaultGITHUB_TOKEN— because Releases published byGITHUB_TOKENdon't propagate events, sodeploy.yml(on: release: [published]) would never fire. Before merging, create the secret:repo), saved as repo secretRELEASE_PLEASE_TOKEN.actions/create-github-app-token.Pilot / next step (the ADR's dry-run gate)
On merge, release-please opens the v2.18.0 release PR batching all 145 commits. That PR is the review checkpoint — inspect the computed bump + CHANGELOG before merging it; merging is the explicit ship-to-prod action (left to you, not automated here).
Refs #1478
Summary by cubic
Automates releases with
release-please, keeping one open release PR onmain. Merging it tagsv*, publishes the Release, and triggersdeploy.yml; usesRELEASE_PLEASE_TOKEN(PAT) so events propagate (ADR #1478).New Features
.github/workflows/release-please.yml(onmain, no auto-merge; merging tagsv*and publishes the Release to triggerdeploy.yml)..release-please-manifest.jsonat2.17.0; addrelease-please-config.json(nodetype forlucky-bot, plainv*tags).release.ymlto prevent duplicate Releases; deploy chain unchanged.Migration
RELEASE_PLEASE_TOKEN(PAT: contents+pull-requests RW) sorelease: publishedtriggersdeploy.ymland the “Allow GitHub Actions to create and approve pull requests” setting isn’t needed.Written for commit 2130099. Summary will update on new commits.
Summary by CodeRabbit