ci: adopt release-please for automated releases - #156
Conversation
WalkthroughAdded Release Please configuration for the root 🚥 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: 1
🧹 Nitpick comments (1)
.github/workflows/release-please.yml (1)
15-15: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winPin the action to an immutable commit.
googleapis/release-please-action@v4is a mutable major tag. Pin a reviewed full commit SHA because this action receivescontents: writeandpull-requests: write.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 75dc7203-5dd3-4078-a0b2-407c44b97538
📒 Files selected for processing (3)
.github/workflows/release-please.yml.release-please-manifest.jsonrelease-please-config.json
| on: | ||
| push: | ||
| branches: [main] | ||
|
|
||
| permissions: | ||
| contents: write | ||
| pull-requests: write | ||
|
|
||
| jobs: | ||
| release-please: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: googleapis/release-please-action@v4 |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Use one release producer for pushes to main.
.github/workflows/ci.yml, Lines 43-69, already runs npx semantic-release for pushes to main. This workflow runs Release Please for the same event. Both tools can create tags and GitHub Releases for the same commits, causing duplicate releases or conflicting tags. Disable the existing release job, or configure one tool to avoid creating tags and GitHub Releases.
…se (#160) release-please was added in #156 alongside the existing semantic-release setup (ci.yml) — both would trigger on push to main, double-releasing or conflicting. This repo already has a working, just-fixed (#159, no committed version file) semantic-release pipeline; it doesn't need a second release mechanism. Removing the release-please addition to leave exactly one.
…-please (#161) Couldn't identify which session/process added release-please (PRs #156-158, merged ~19:36-19:44 UTC today) — no aoe session had a path in this repo, opencode's and omp's session DBs show no matching activity, and history:// only sees this process's own subagents. Whatever did it either ran outside any locally-tracked session or has since exited without leaving a trace I can query. Since I can't message the specific process, asserting the policy durably in the repo instead: AGENTS.md already documented 'creates release via semantic-release' in its Post-PR workflow section, but nothing said not to add a second mechanism alongside it. Now it does, explicitly, with the incident referenced by PR number.
1 participant
Replaces manual v* tag pushes with googleapis/release-please-action, which automatically tags and creates GitHub Releases on every merge to main based on conventional-commit messages.