ci: fix ready-for-review label automation for fork pull requests#838
Conversation
Fork pull requests run the `pull_request` and `pull_request_review` events with a read-only `GITHUB_TOKEN` and no access to secrets, so the `evaluate` job could not mutate labels and failed with "Resource not accessible by integration" when it tried to add `ready-for-review` after CodeRabbit approved. The privileged `workflow_run` path that should have covered this was a silent no-op for forks because `github.event.workflow_run.pull_requests` is always empty for cross-repository PRs. Restructure the automation around the `workflow_run` relay pattern. A new lightweight `Ready for Review Trigger` workflow runs on `pull_request` and `pull_request_review`, does nothing but complete, and thereby fires a `workflow_run` event. The `Ready for Review Label` workflow now runs only on `workflow_run`, where it holds a write-capable token even for forks, resolves the PR by matching the head sha against the open pull requests (the commit-to-PR endpoint does not index fork heads), and applies or removes the label. No new secrets are required. Fold the dismissal, changes-requested and merge-conflict handling into the single re-evaluation path and exclude the relay job from the CI gate.
|
Warning Review limit reached
Next review available in: 43 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 (2)
📝 WalkthroughWalkthroughA new GitHub Actions workflow relays pull request and review events to trigger a downstream workflow_run-based process. The existing ready-for-review workflow is rewritten to consume workflow_run events, resolve PRs by head_sha, and add/remove the ready-for-review label based on merge-conflict labels and CodeRabbit review state. The CI status script excludes the new trigger job. ChangesCI Workflow Trigger and Label Management
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant GitHub
participant ReadyForReviewTrigger
participant ReadyForReviewWorkflow
participant CodeRabbit
GitHub->>ReadyForReviewTrigger: pull_request/pull_request_review event
ReadyForReviewTrigger->>ReadyForReviewTrigger: relay job completes
GitHub->>ReadyForReviewWorkflow: workflow_run completed event
ReadyForReviewWorkflow->>GitHub: find open PRs matching head_sha
ReadyForReviewWorkflow->>GitHub: check draft status and merge-conflict label
ReadyForReviewWorkflow->>CodeRabbit: check latest review state
CodeRabbit-->>ReadyForReviewWorkflow: review state (APPROVED or not)
ReadyForReviewWorkflow->>GitHub: add or remove ready-for-review label
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #838 +/- ##
==========================================
+ Coverage 73.13% 73.49% +0.36%
==========================================
Files 324 324
Lines 72562 72562
==========================================
+ Hits 53066 53331 +265
+ Misses 19496 19231 -265
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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/ready-for-review-trigger.yml:
- Line 9: The PR review trigger in ready-for-review-trigger.yml only listens for
ready_for_review and labeled, so it misses draft conversions; add
converted_to_draft to the trigger and update the ready-for-review workflow logic
in .github/workflows/ready-for-review.yml so the draft path removes the
ready-for-review label instead of skipping. Use the workflow names
ready-for-review-trigger and ready-for-review to locate the event handling and
label-clearing behavior.
In @.github/workflows/ready-for-review.yml:
- Around line 21-24: The workflow permissions block is overriding the default
repo read access, which can break both actions/checkout@v4 steps before the
label logic runs. Update the permissions in ready-for-review.yml to include
contents: read alongside the existing pull-requests, checks, and issues scopes,
and if evaluate gets a separate permissions block, ensure it keeps the mutating
scopes plus contents: read as well.
🪄 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: CHILL
Plan: Pro
Run ID: 40ed1256-d930-43c7-bfcc-cdbd83aa8306
📒 Files selected for processing (3)
.github/scripts/check_ci_status.sh.github/workflows/ready-for-review-trigger.yml.github/workflows/ready-for-review.yml
Setting a workflow-level `permissions` block drops the default `contents: read`, which both `actions/checkout@v4` steps need. Restore it alongside the existing scopes. Addresses CodeRabbit review comment on PR dashpay#838 dashpay#838 (comment)
The trigger workflow did not relay `converted_to_draft`, so converting a labeled PR back to draft fired no `workflow_run` and the label survived. Relay that event and make the draft branch remove the label instead of skipping, matching the defensive `|| true` used by the sibling merge-conflict and CodeRabbit branches so a `gh` hiccup on one PR does not abort a multi-PR batch. Addresses CodeRabbit review comment on PR dashpay#838 dashpay#838 (comment)
1 participant
Problem
The
ready-for-reviewlabel automation has never worked for pull requests opened from a fork, which is the normal case for contributor PRs. Two compounding causes:Read-only token, no secrets. For fork PRs, GitHub runs the
pull_requestandpull_request_reviewevents with a read-onlyGITHUB_TOKENand no access to secrets. So theevaluatejob could not add or remove labels. When CodeRabbit approved a PR whose CI was already green (e.g. fix(key-wallet): don't build asset locks on unconfirmed funds #836), the job hit every gate and then died onaddLabelsToLabelablewithResource not accessible by integration. This is also why a GitHub App token or PAT cannot help on that event: the secret holding the key is unavailable there.Silent no-op on the privileged path. The workflow already had a
workflow_runtrigger, which does get a write token even for forks. But it read the PR number fromgithub.event.workflow_run.pull_requests, and that array is always empty for cross-repository (fork) PRs. A real run log showedNo associated pull requests found, skipping, so the label was never applied even after CI passed.The prior fix (#811) only added
issues: writeto the job, which does nothing for forks.Fix
Restructure around the GitHub-recommended
workflow_runrelay pattern. No new secrets are needed.Ready for Review Triggerworkflow (ready-for-review-trigger.yml): runs onpull_requestandpull_request_reviewwithpermissions: {}. It does nothing but complete, which fires aworkflow_runevent. This is the only way a CodeRabbit approval (apull_request_review) can reach a privileged context on a fork PR.Ready for Review Labelworkflow (ready-for-review.yml) now runs only onworkflow_run(the CI workflows plus the new trigger), where it holds a write-capable token for forks. It resolves the PR by matchingworkflow_run.head_shaagainst the open pull requests, because thecommits/{sha}/pullsendpoint does not index fork heads (verified against fix(key-wallet): don't build asset locks on unconfirmed funds #836). Matching the exact head sha also ignores stale runs whose commit the PR has moved past.!= APPROVEDor amerge-conflictlabel removes the label).check_ci_status.sh.The applier never checks out or runs fork code (sparse-checkout of
.github/scriptsfrom the base only), so there is no pwn-request risk.Validation caveat
workflow_runworkflows always execute the default-branch (dev) version of the workflow. So the applier half of this change cannot be fully exercised from this PR branch, it only takes effect once merged todev. The trigger workflow runs from the PR branch and is observable here. Locally verified:actionlintclean, pre-commit (including the actionlint hook) passing,validate-triggerscoverage check passes with the new workflow, and the head-sha PR resolution returns the correct PR for the fork PR #836.Summary by CodeRabbit
New Features
Bug Fixes