try using another api for checking #53
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughSwitches PR workflow trigger to Changes
Sequence Diagram(s)sequenceDiagram
participant PR as Pull Request
participant Runner as Actions Runner
participant API as GitHub REST API
participant GraphQL as GitHub GraphQL
participant Repo as Repository Labels
PR->>Runner: trigger (pull_request_target)
Runner->>API: fetch current PR labels, size calculation
API-->>Runner: current labels, PR data
Runner->>API: getCollaboratorPermissionLevel(author)
API-->>Runner: permission (admin/maintain | other)
alt maintainer (admin/maintain)
Runner->>Repo: apply "org-member" label (use LABELLER_TOKEN)
else non-maintainer
Runner->>API: fetch author commit count
API-->>Runner: commit count
alt first-time contributor (≤1)
Runner->>Repo: apply "first-time-contributor"
else repeat contributor
Runner->>Repo: apply "repeat-contributor"
end
end
Runner->>GraphQL: query review threads for CodeRabbit comments
GraphQL-->>Runner: threads (resolved/unresolved)
alt unresolved CodeRabbit threads exist
Runner->>Repo: add "unresolved-code-rabbit-review"
else none
Runner->>Repo: remove "unresolved-code-rabbit-review" if present
end
Runner->>Repo: update size label (remove outdated, apply calculated) / log outcome
sequenceDiagram
participant Trigger as Manual / Push
participant Runner as Actions Runner
participant API as GitHub API
participant Repo as Repository Labels
Trigger->>Runner: run setup-labels workflow
Runner->>API: list existing labels (paginated)
API-->>Runner: existing labels
loop for each desired label
Runner->>API: compare/create/update label (color/description)
API-->>Runner: created / updated / skipped / failed
end
Runner->>Repo: output summary (created/updated/skipped/failed)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (1 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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/sync-pr-labels.yml (1)
265-277: Fix first‑time contributor threshold (≤1 mislabels prior contributors).
repos.listCommitsreturns commits from the default branch. When filtering byauthor: prAuthor, a user with exactly one prior commit will still be mislabeled as first-time due to the<= 1condition. Use=== 0to detect only users with no prior commits (optionally addper_page: 2to avoid fetching unnecessary data).🔧 Proposed fix
- const commits = await github.rest.repos.listCommits({ + const commits = await github.rest.repos.listCommits({ owner: context.repo.owner, repo: context.repo.repo, - author: prAuthor + author: prAuthor, + per_page: 2 }); @@ - if (commits.data.length <= 1) { + if (commits.data.length === 0) { contributorLabels.push('first-time-contributor'); } else { contributorLabels.push('external-contributor'); }
🤖 Fix all issues with AI agents
In @.github/workflows/sync-pr-labels.yml:
- Around line 281-289: The permission check for labeling maintainers uses the
wrong API value: when calling github.rest.repos.getCollaboratorPermissionLevel
(result stored in permissionLevel) the permission field returns "write" for
maintain-role users, not "maintain", so update the conditional that pushes into
contributorLabels (currently checking ['admin','maintain']) to check for
['admin','write'] instead, or alternatively inspect
permissionLevel.data.role_name if you need to distinguish the actual "maintain"
role; update the if that references permissionLevel.data.permission accordingly
and keep prAuthor and contributorLabels usage intact.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/sync-pr-labels.yml:
- Around line 281-283: The PR uses non-existent labels: replace
contributorLabels.push('Org-Member') and any usage of 'external-contributor' in
the addLabels call with repository-defined labels (e.g., remove or replace
'Org-Member' with an appropriate existing label, and change
'external-contributor' to 'repeat-contributor'); update the logic around
contributorLabels and isMaintainer in the code that calls addLabels so it only
pushes valid labels (and/or create the 'Org-Member' label in repo config if you
intend to keep that name) to avoid silent failures from addLabels.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.github/workflows/setup-labels.yml:
- Around line 189-203: Add a failing condition when any label operation failed:
after the existing summary block that references created/updated/skipped/failed,
check if failed > 0 and call core.setFailed(`Label setup failed: ${failed}
operations failed`) to mark the step as failed; keep the existing
success/complete console logs but ensure core.setFailed is invoked when failed >
0 (use the core import and the failed variable present in the script).
- Around line 138-145: The code uses github.rest.issues.listLabelsForRepo which
returns only the first page; replace that call with github.paginate to fetch all
labels (e.g., use github.paginate(github.rest.issues.listLabelsForRepo, { owner:
context.repo.owner, repo: context.repo.repo }) ), then derive existingLabelNames
from the combined result instead of the paged single response; update any uses
of existingLabels/existingLabelNames accordingly so no labels are missed and 422
errors are avoided.
…improve failure handling
| description: 'JavaScript/TypeScript code changes' | ||
| }, | ||
| { | ||
| name: 'python', |
There was a problem hiding this comment.
Not all repos contain Python code. Should we really have this label?
There was a problem hiding this comment.
GitHub auto-creates a label when we request GitHub bot to apply a label (if we not create that label), but those labels have no descriptions and all use the same color #ededed , see:
This setup explicitly defines a small, clean label set with proper descriptions and colors which include common language js, py
The main reason for introducing this workflow was the internal check pointing out the need for a contributor labels:
https://github.com/AOSSIE-Org/Template-Repo/actions/runs/21186875613/job/60943766803?pr=52
Language labels can always be adjusted per repo if needed
and also note that this is execute on workflow_dispatch means you need to manual trigger it for apply
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/sync-pr-labels.yml (1)
3-5:⚠️ Potential issue | 🟠 Major
pull_request_target— be aware of payload injection risks.Using
pull_request_targetgrants write access and secrets to the workflow. While you don't checkout fork code (good), several steps interpolate PR-controlled data into inline scripts via${{ }}expressions (e.g., line 140 with file names). A malicious filename containing'could break theJSON.parseon line 140. Consider using environment variables instead of direct expression interpolation for untrusted data:env: CHANGED_FILES: ${{ steps.changed-files.outputs.files }}then in script:
JSON.parse(process.env.CHANGED_FILES)This is a general hardening recommendation for
pull_request_targetworkflows.
🤖 Fix all issues with AI agents
In @.github/workflows/sync-pr-labels.yml:
- Around line 322-328: The comment heading "# STEP 5: CodeRabbit review status
labels" is indented inconsistently; align its indentation to match other step
comments (e.g., the same leading spaces used for "# STEP 1/2/3/4" blocks) so the
block starting with the "Check CodeRabbit review status" step (uses:
actions/github-script@v7 and the script: | section referencing prNumber) follows
the same visual indentation as the other steps—adjust the leading spaces before
"# STEP 5: CodeRabbit review status labels" to match the existing step comment
style.
- Around line 425-428: The catch block currently calls
core.setFailed(error.message) which fails the whole workflow for a non-critical
labeling step; replace that call with a non-fatal logging call (e.g.,
core.warning or core.error) and keep the existing console.log so the error is
recorded but the job does not abort — update the catch that surrounds the
CodeRabbit GraphQL check (the try/catch referencing "Error checking CodeRabbit
review status" and core.setFailed) to remove core.setFailed and use
core.warning/core.error instead so execution continues on transient or
rate-limit failures.
- Around line 366-373: The current filter in unresolvedCodeRabbitThreads uses
comment.author.login.toLowerCase().includes("coderabbit") which can produce
false positives; change the check to an exact match against the known bot login
(e.g., comment.author.login && comment.author.login.toLowerCase() ===
"coderabbit") or whatever the canonical bot login is, so replace the
includes(...) call with a strict equality comparison while keeping the existing
null checks around comment.author and comment.author.login.
- Around line 299-306: Before applying contributor labels, remove any stale
contributor/org-member labels so only the correct one is present: inspect
contributorLabels (and isMaintainer/commits.data) logic and, prior to pushing
new labels, call the same label-removal pattern used in the size-label step to
strip any of ['first-time-contributor','repeat-contributor','org-member'] that
may already be on the PR; then add the single correct label (if isMaintainer add
'org-member' and remove both contributor labels, else remove the opposite
contributor label before adding either 'first-time-contributor' or
'repeat-contributor').
This reverts commit f29a36a.
2 participants
Summary by CodeRabbit
New Features
Chores