Refactor CodeRabbit approval workflow to use pull_request_target and …

[kpj2006]

…enhance review handling

Addressed Issues:

Fixes #(issue number)

Screenshots/Recordings:

Additional Notes:

Checklist

• My code follows the project's code style and conventions
• I have made corresponding changes to the documentation
• My changes generate no new warnings or errors
• I have joined the Discord server and I will share a link to this PR with the project maintainers there
• I have read the Contributing Guidelines

⚠️ AI Notice - Important!

We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact.

Summary by CodeRabbit

• Chores
  • Updated internal GitHub Actions workflow configuration and approval detection mechanism.

[coderabbitai]

Warning

Rate limit exceeded

@kpj2006 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 0 minutes and 34 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 0 minutes and 34 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 98e8a199-0e07-4472-a0b9-a3b7c6fb9d46

📥 Commits

Reviewing files that changed from the base of the PR and between b22e817 and 721ca48.

📒 Files selected for processing (2)

• .github/workflows/coderabbit-approval-dispatch.yml
• .github/workflows/coderabbit-approval.yml

Walkthrough

The GitHub Actions workflow trigger was changed from pull_request_review events to pull_request_target events. The approval detection logic was refactored to query CodeRabbit reviews via GitHub API instead of using the webhook payload, and the authentication token source was updated to use github.token.

Changes

Cohort / File(s)	Summary
Workflow Configuration .github/workflows/coderabbit-approval.yml	Changed trigger from pull_request_review (submitted) to pull_request_target (opened, reopened, synchronize, ready_for_review); updated approval detection to fetch reviews via github.rest.pulls.listReviews, filter for CodeRabbit's latest review, and check APPROVED state; switched GitHub token from secrets.EXTERNAL_LABELLER_TOKEN || secrets.GITHUB_TOKEN to ${{ github.token }}.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Add CodeRabbit approval handler and sync PR labels for review status #64: Adds the workflow and approval/label-sync logic that this PR modifies and refactors.
• Refactor CodeRabbit approval handler to use external labeller token f… #70: Also modifies the same workflow file and changes GitHub token sourcing/usage patterns.

Suggested reviewers

• Zahnentferner

Poem

🐰 Hops through workflows with glee,
From reviews old, to API calls new,
Triggers dance, tokens align with care,
CodeRabbit stamps its bright approval there! ✨

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title summarizes the main change—refactoring the approval workflow to use pull_request_target—which aligns with the core objective described in the PR summary and the workflow file modifications shown in the raw summary.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/coderabbit-approval.yml (1)

105-127: 🧹 Nitpick | 🔵 Trivial

Consider checking if label already exists before adding.

The addLabels API is idempotent (adding an existing label is a no-op), so this works correctly. However, for consistency with the removal step's pattern and clearer logging, you could check existence first.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/coderabbit-approval.yml around lines 105 - 127, Before
calling github.rest.issues.addLabels in the "Add CodeRabbit approved label"
step, fetch existing labels for the PR (e.g., via
github.rest.issues.listLabelsOnIssue or context payload's pull_request.labels)
and check whether 'coderabbit-approved' is already present for prNumber; if
present, log that the label exists and skip addLabels, otherwise call
github.rest.issues.addLabels for prNumber and log the addition—use the same
variables (prNumber, github.rest.issues.addLabels) and keep the try/catch around
the conditional flow for consistent error handling and logging.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/coderabbit-approval.yml:
- Around line 4-5: The workflow's trigger is wrong: it uses pull_request_target
with types [opened, reopened, synchronize, ready_for_review] which causes it to
run before any CodeRabbit review exists; change the trigger to listen for
pull_request_review with types: [submitted] (or use a workflow_run that fires
after a pull_request_review) so the job runs when a review is submitted and can
detect/act on CodeRabbit approvals; update the top-level trigger stanza (replace
pull_request_target/types or add a workflow_run alternative) so the workflow
executes on actual review submissions rather than PR lifecycle events.

---

Outside diff comments:
In @.github/workflows/coderabbit-approval.yml:
- Around line 105-127: Before calling github.rest.issues.addLabels in the "Add
CodeRabbit approved label" step, fetch existing labels for the PR (e.g., via
github.rest.issues.listLabelsOnIssue or context payload's pull_request.labels)
and check whether 'coderabbit-approved' is already present for prNumber; if
present, log that the label exists and skip addLabels, otherwise call
github.rest.issues.addLabels for prNumber and log the addition—use the same
variables (prNumber, github.rest.issues.addLabels) and keep the try/catch around
the conditional flow for consistent error handling and logging.

🪄 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: 535e0a83-2e0f-4162-9230-8cebe6875f5c

📥 Commits

Reviewing files that changed from the base of the PR and between 6ef9363 and b22e817.

📒 Files selected for processing (1)

• .github/workflows/coderabbit-approval.yml