ci(pr-triage): unify labeler, priority triage, and label policy - #731
Conversation
The label-policy workflow ran on every issue and on every PR synchronize, producing two kinds of noise: - Issues opened by external contributors failed the check because priority and routing are maintainer-side triage labels the author cannot reasonably set. The red check looked like an issue-template problem to the reporter. - PRs with a wrong label combination (e.g. P1+P2 on #729) failed again on every commit push because synchronize re-triggered the workflow even when labels had not changed. Scope the check to PR events that actually change labels (opened, labeled, unlabeled, reopened) and stop running it on issues. Issue triage is owned by saved-search views, not CI. Also disable blank_issues_enabled so issue authors must go through a template, which guarantees a type label (bug/enhancement/task) on creation. The #728 untriaged-issue case came from the blank entry point. Update the meta-test to lock the new trigger contract and to drop the issues: read permission assertion.
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
✨ 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 |
github-actions
Bot
added
ci
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request disables blank issues and updates the label policy workflow tests to target pull requests on the 'dev' branch while removing issue triggers. A review comment identifies that removing the 'issues: read' permission will likely cause a 403 Forbidden error because the workflow still utilizes the Issues API to list labels, and suggests restoring this permission to ensure the workflow functions correctly.
The labeler, pr-priority-triage, and label-policy workflows all fired on pull_request_target opened in parallel. label-policy read labels before labeler and pr-priority-triage had finished writing them, then failed on missing priority or routing. Because GITHUB_TOKEN label writes do not trigger downstream workflows, the failed run stuck until a maintainer re-ran it or a new push arrived. This is the race that produced the first-attempt failure on PR #731. Merge the three workflows into a single pr-triage workflow. Labeler runs first, then the github-script step computes the priority label, syncs it, posts the recommendation comment, and finally calls validateLabelPolicy against the labels that exist after all writes. The check is now physically incapable of racing the labelers. Trade-off: label-policy no longer fires on manual labeled / unlabeled events. Maintainer-introduced label errors after a PR stops receiving pushes are caught by reviewer eyes or by the next push (which re-runs pr-triage). Production data across 30 recent PRs shows zero cases of this scenario, so the gap is acceptable; if it ever bites, restoring a tiny labeled-event workflow is a five-line follow-up. Also rename so the workflow name reflects its actual scope, and update the meta-test contract to match. If dev branch protection lists pr-priority-triage or label-policy as a required status check, update those entries to pr-triage.
Astro-Han
changed the title
1 participant
Summary
Merge three parallel pull_request_target workflows (labeler, pr-priority-triage, label-policy) into a single pr-triage workflow. Disable blank issues. Update the meta-test contract.
Why
Three GitHub Actions workflows were racing on every PR opened. labeler wrote routing labels, pr-priority-triage wrote a priority label, and label-policy read labels and checked completeness. They ran in parallel, so label-policy could read labels before the writers finished and fail with "missing priority" or "missing routing." Because pr-priority-triage and labeler both use GITHUB_TOKEN to add labels, those writes do not trigger any downstream workflow run, so the failed label-policy check stayed red until a maintainer re-ran it or a new push arrived. This race produced the first-attempt failure on this PR itself.
Issues opened by external contributors also failed the check, since priority and routing are maintainer-side triage labels the author cannot reasonably set. The red mark looked like an issue-template problem to the reporter. Issue triage is owned by saved-search views, not CI.
The fix moves the three workflows into a single pr-triage workflow with three sequential steps. actions/labeler runs first and writes routing. github-script then computes priority, syncs the P label, posts the recommendation comment, and finally calls validateLabelPolicy against the labels that exist after all writes. The check is physically incapable of racing the writers because there is no parallelism left.
Blank issues are disabled because the bug, feature, and task templates already carry a type label on creation. The blank entry point was the path that produced no-label issues like #728.
Related Issue
No issue. Driven by the failure pattern visible in recent label-policy runs and the race that first-failed this PR.
Human Review Status
Pending. A human should make the final merge decision after reviewing the final diff and verification evidence.
Review Focus
Risk Notes
How To Verify
Screenshots or Recordings
Not applicable. CI configuration change with no visible UI surface.
Checklist