ci: park release-please until 0.1.0 beta baseline#575
Conversation
Switch the Release Please workflow to workflow_dispatch-only so it stops failing on every push to main. With no prior release and a 0.0.0 manifest, release-please builds one initial release PR from all of main's history; the changelog overflows GitHub's PR-body limit and the run errors trying to spill to a release-notes.md branch that doesn't exist. The job is not a required check, so this is non-blocking noise rather than a merge gate. Baselining now would only be redone after the pending business-org migration, so park the push trigger and re-enable it at beta time once the manifest is seeded to 0.1.0 and a curated v0.1.0 release/tag exists. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe ChangesRelease-please Trigger Change
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 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 |
![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
🤖 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 14-15: Update the documentation in the CI docs section that
describes the release-please workflow behavior. Currently it states that
release-please runs on every push to main, but the workflow configuration now
shows it only triggers via workflow_dispatch (manual trigger). Change the
documentation to accurately reflect that release-please is now a manual-only
trigger rather than an automatic one to prevent operator confusion.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 299e17fc-4208-4391-b5eb-71bb2e26e6e0
📒 Files selected for processing (1)
.github/workflows/release-please.yml
| on: | ||
| push: | ||
| branches: [ main ] | ||
| workflow_dispatch: |
There was a problem hiding this comment.
Update CI docs to match manual-only release trigger
docs/ci.md still says release-please runs on every push to main, but this workflow is now workflow_dispatch only. Please update that section to avoid operator confusion during the parked period.
🤖 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 14 - 15, Update the
documentation in the CI docs section that describes the release-please workflow
behavior. Currently it states that release-please runs on every push to main,
but the workflow configuration now shows it only triggers via workflow_dispatch
(manual trigger). Change the documentation to accurately reflect that
release-please is now a manual-only trigger rather than an automatic one to
prevent operator confusion.
☀️ Quality Summary 🚦 build-linux-gcc: 100% successful (✔️ 1521 passed) Created by Quality Monitor v1.14.0 (#f3859fd). More details are shown in the GitHub Checks Result. |
1 participant
What
Switch the Release Please workflow to
workflow_dispatch-only so it stops failing on every push tomain.Why
With no prior release and a
0.0.0manifest, release-please tries to build a single initial release PR from all ofmain's history (~351 commits). That changelog overflows GitHub's ~64 KB PR-body limit, and the run then errors trying to spill the body to arelease-please--branches--main--release-notesbranch that doesn't exist:It's been red on every main push for many runs. It is not in the branch-protection required checks, so this is non-blocking noise (red X + failure emails), not a merge gate.
Baselining release-please now would only be redone after the pending migration to the business GitHub org, so parking the push trigger is the lowest-effort fix.
Re-enabling (at beta time)
Restore
on: push: branches: [main], after:.release-please-manifest.jsonseeded to0.1.0, andv0.1.0release/tag exists,so release-please manages
0.1.xonward incrementally. Until then it can still be run by hand from the Actions tab (workflow_dispatch).🤖 Generated with Claude Code
Summary by CodeRabbit