-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: replace PR "Request Changes" with a "API CHANGES REQUESTED" comment #163
feat: replace PR "Request Changes" with a "API CHANGES REQUESTED" comment #163
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand it API review is supposed to be separate from PR functionality review. I'm uncomfortable making PR approvals equivalent for API approvals.
Ya there's a similar discussion happening in the API WG about distinguishing between PR review and API review. I'll mark this as WIP until we reach consensus on the desired behavior. |
@@ -170,7 +170,7 @@ describe('api review', () => { | |||
data: [ | |||
{ | |||
user: { id: 1, login: 'ckerr' }, | |||
body: 'Fix this please!', | |||
body: 'API CHANGES REQUESTED', | |||
state: 'CHANGES_REQUESTED', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use the Request Changes feature in GitHub, but it will only have an impact on API review if you also include API CHANGES REQUESTED
in your comment.
Updated implementation and PR description to match the new approach we discussed in API WG. PR approvals/change requests are ignored, and instead only specific comment strings are used to approve/decline/request changes to the API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for updating this :)
This PR: electron/electron#42561 illustrates an odd edge case in our approve/request changes workflow. If you request changes on the PR, the API Review is blocked (even if you were requesting changes to implementation or other non-API parts of the PR). If you subsequently approve the PR, the API Review is still blocked because we don't consider PR approvals to be API approvals.
After some discussion within the API WG, the consensus is that submitting a "Request Changes" to a PR should not be implicitly treated as an API request for changes. Instead, we should add an additional comment match for
API CHANGES REQUESTED
and use that to denote that a reviewer has requested changes to the API.This PR implements this proposal, by removing checks for
REQUEST_CHANGES
reviews on the PR, and instead looking forAPI CHANGES REQUESTED
text in PR review comments.When this lands, there will be 3 comment strings that will change the API Review state:
API LGTM
- adds one sign-off for the PR's API changesAPI CHANGES REQUESTED
- indicates that changes have been requested for the API. API Review workflow will not be approved while anAPI CHANGES REQUESTED
is active.API DECLINED
- indicates that the reviewer doesn't think this API should be added. API Review workflow will not be approved while anAPI DECLINED
is active.As has always been the case, the last review by each API WG member is evaluated by cation, so an
API CHANGES REQUESTED
orAPI DECLINED
can be "cleared" by adding a follow-upAPI LGTM
comment.