mirror of
https://github.com/strands-agents/harness-sdk.git
synced 2026-10-02 02:44:48 +08:00
ci: enforce API review label requirement before merge (#2716)
Co-authored-by: Mackenzie Zastrow <zastrowm@users.noreply.github.com>
This commit is contained in:
co-authored by
Mackenzie Zastrow
parent
61c1695bd1
commit
bb164d2251
@@ -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
|
||||
|
||||
@@ -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.');
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user