ci: enforce API review label requirement before merge (#2716)

Co-authored-by: Mackenzie Zastrow <zastrowm@users.noreply.github.com>
This commit is contained in:
Mackenzie Zastrow
2026-06-10 16:55:37 -04:00
committed by GitHub
co-authored by Mackenzie Zastrow
parent 61c1695bd1
commit bb164d2251
3 changed files with 37 additions and 2 deletions
+1 -1
View File
@@ -1,6 +1,6 @@
---
name: pr-writer
description: Generates pull request titles and descriptions. Use when the user asks to write, draft, or generate a PR, pull request, or merge request description.
description: Generates pull request titles and descriptions. Use when the user asks to create, open, write, draft, or generate a PR, pull request, or merge request description.
---
# PR Writer Skill
+35
View File
@@ -0,0 +1,35 @@
name: API Review Label Check
on:
pull_request_target:
branches: [main]
types: [opened, reopened, synchronize, labeled, unlabeled]
jobs:
check-api-review-label:
runs-on: ubuntu-latest
permissions:
pull-requests: read
steps:
- name: Enforce api/review-complete when api/needs-review is present
uses: actions/github-script@v9
with:
script: |
const labels = context.payload.pull_request.labels.map(l => l.name);
const needsReview = labels.includes('api/needs-review');
const reviewComplete = labels.includes('api/review-complete');
if (!needsReview && !reviewComplete) {
core.info('No API review labels present — skipping check.');
return;
}
if (needsReview && !reviewComplete) {
core.setFailed(
'This PR has the "api/needs-review" label but is missing "api/review-complete". ' +
'An API reviewer must complete their review before this PR can be merged.'
);
return;
}
core.info('API review is complete.');
+1 -1
View File
@@ -69,7 +69,7 @@ The process for designating an API reviewer depends on the scope and stage of yo
For **standard PR reviews**, identify an engineer with API development experience to serve as your API reviewer. They should review the proposal from the API Reviewer Role perspective—focusing on customer usage and public API design rather than diving into implementation details. With proper preparation, the API reviewer should be able to understand and evaluate your proposal entirely from the PR description, making the review efficient and focused.
To indicate that a PR requires API review, add the `needs-api-review` label. Once the API reviewer has completed their evaluation and any necessary changes have been addressed, replace it with the `completed-api-review` label. This makes it easy to track which PRs are awaiting review and which have been approved from an API perspective.
To indicate that a PR requires API review, add the `api/needs-review` label. Once the API reviewer has completed their evaluation and any necessary changes have been addressed, add the `api/review-complete` label. A CI check enforces that PRs with `api/needs-review` cannot be merged without `api/review-complete`. This makes it easy to track which PRs are awaiting review and which have been approved from an API perspective.
For **larger features** that require more extensive discussion, schedule a meeting with your designated API reviewer to walk through use cases and API design decisions. These sessions can be formal or informal depending on feature complexity. Individual or medium-sized features can take 30-60 minutes of discussion, while larger features may benefit from multiple sessions throughout the design and implementation phases. The goal is to catch potential issues early while maintaining fast iterations on feature development.