ci: grant issues write to release-please for autorelease labels#1821
Conversation
release-please creates and applies the `autorelease: pending` / `autorelease: tagged`
labels through GitHub's Issues API. Without `issues: write` the labeling step 403s
("Resource not accessible ...") after the Release PR is created, failing the whole run.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 48 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: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis change adds an ChangesRelease Workflow Permissions
Estimated code review effort: 1 (Trivial) | ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
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:
- Line 24: The workflow currently grants issues: write at the top level, which
applies to every job in release-please.yml instead of only the job that mutates
labels. Move this permission from the workflow scope into the release-please
job’s permissions block so only that job can call the Issues API. Keep the
existing label-related access intact for the release-please job, and leave other
jobs at the default least-privilege level.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0b68e6b5-3ef5-4815-82ab-b9703b3fbc31
📒 Files selected for processing (1)
.github/workflows/release-please.yml
zizmor flagged workflow-level `issues: write` as overly broad — it applied to every job (incl. publish). Move it into the release-please job's permissions block (least-privilege); since a job-level block overrides the workflow default, contents/pull-requests are re-declared there. The publish job keeps the workflow-level contents:write it needs for release-asset upload. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem
The Release Please workflow has been failing on every push to
masterwith:release-please gets all the way through creating the tree/commit, updating the branch ref, and creating the Release PR (#1814) — then 403s on the labeling step. It applies
autorelease: pending/autorelease: taggedto the Release PR via GitHub's Issues API, which needsissues: write. The workflow only grantedcontents: write+pull-requests: write.Fix
Add
issues: writeto thepermissions:block so the label management works (and theGITHUB_TOKENfallback path is fully functional).Note
The workflow authenticates with
AUTOFIX_PAT, and a token's permissions aren't governed by the workflowpermissions:block — so theAUTOFIX_PATfine-grained token also needsIssues: Read and writeadded for the primary (PAT) path. That's a settings change on the token itself; this PR covers the workflow side. The twoautorelease:labels have also been pre-created in the repo.🤖 Generated with Claude Code
Summary by CodeRabbit