chore: Keep Release Please PRs readable and unblocked#1451
Conversation
Release PRs can list component names in summary headings, such as unity-package: 3.0.0-beta.47. Parse those summaries so published release PRs do not keep stale autorelease: pending labels and block later release-please runs.
|
Warning Review limit reached
Next review available in: 20 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughUpdates release PR body rewriting to use component labels, wires the new clarifier into release checks and tests, and broadens published release label sync to handle component-prefixed summaries. ChangesRelease automation updates
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
Release Please writes grouped component details with version-only Markdown headings, which makes release PRs look like duplicate package releases. Label generated headings with component display names while preserving the existing summary fallback.
Component-prefixed release PR summaries identify which release tag format should be checked. Carry the component into tag construction so project runner release PRs look for uloop-project-runner-v tags instead of package v tags.
There was a problem hiding this comment.
1 issue found across 2 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="scripts/sync-published-release-pr-labels.sh">
<violation number="1" location="scripts/sync-published-release-pr-labels.sh:41">
P2: Prefer the body-derived component tag before the title-derived generic tag. Otherwise project-runner release PRs with numeric release titles keep looking up v<version> and never clear the pending label after uloop-project-runner-v<version> is published.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
Match the project name casing in generated Release Please component headings so project runner entries are labeled as uloop Project Runner.
Review feedback showed that legacy numeric release titles can hide the component-specific tag in grouped Release Please bodies. Use the body-derived component tag first, then fall back to the title so project runner release PR labels clear after uloop-project-runner-v releases publish.
There was a problem hiding this comment.
1 issue found across 2 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
Strengthen the release label sync regression test so it fails if numeric release titles trigger a generic v tag lookup before the component-derived project runner tag.
Summary
User Impact
Changes
unity-package: 3.0.0-beta.47anduloop-project-runner: 3.0.0-beta.45.Verification
go test ./internal/automation -count=1scripts/test-release-please-config.shscripts/test-sync-published-release-pr-labels.shscripts/test-mark-release-pr-tagged.shgit diff --checkscripts/check-go-cli.shautoreview --mode branch --base origin/v3-beta