Add GitHub workflow to automatically assign PRs #370
Conversation
Our repositories require that every pull request have two approvals before they can be merged. Often, what will happen is a team will be added as a requested reviewer but then the first person who reviews performs their review "on behalf of" the team. That's pretty cool but it also means that there are no longer any assigned reviewers! This further means that for anyone using the [Review requests][1] tab on GitHub, they don't see that PR still needs to be reviewed. This new workflow takes care of that by just re-requesting review from the team until the review threshold has been met. For simplicity in the implementation, it pauses asking for reviews once someone has requested changes (but that matches our branch protection rules anyway). Because assigning team reviewers requires permissions not available on the `GITHUB_TOKEN`, creating a workflow like this previously would have been a bit of a complication but we're now able to leverage the same GitHub App that we're using for our other workflow automation (without having to request a PAT). [1]: https://github.com/pulls/review-requested
| private_key: ${{ secrets.APP_PRIVATE_KEY }} | ||
| - name: Assign reviewers | ||
| uses: actions/github-script@v6 | ||
| if: steps.pr-reviews.outputs.review-decision == 'REVIEW_REQUIRED' |
There was a problem hiding this comment.
My only question regarding this is what is the desired result if one person request changes and then someone else comments on the PR? Won't that lead to a review decision of 'REVIEW_REQUIRED'?
There was a problem hiding this comment.
Nope! This checks the overall status of the PR. Which really basically is:
- If any reviews are "Request Changes", then the status is "Changes Requested". End
- If there are a a sufficient number of "Approve"s, then the status is "Approved". End
- The status is "REVIEW_REQUIRED"
|
Oh wow!! I didn't realize that it would start operating now! That's interesting! |
This will help us correlate runs in the Actions tab.
|
I talked with @mikeisen1 about this briefly the other day. Obviously, we'll want to eventually find a way to get this to work on all our repositories. Unfortunately, GitHub doesn't really have a builtin a way to do that today; so we'll have to just copy-and-paste it to other repositories for now. One potentially-interesting option would be to use some sort of webhook-driven model (rather than GitHub Actions) but that would require a server implementation. |
Our repositories require that every pull request have two approvals
before they can be merged. Often, what will happen is a team will be
added as a requested reviewer but then the first person who reviews
performs their review "on behalf of" the team. That's pretty cool but it
also means that there are no longer any assigned reviewers! This further
means that for anyone using the Review requests tab on GitHub, they
don't see that PR still needs to be reviewed.
This new workflow takes care of that by just re-requesting review from
the team until the review threshold has been met. For simplicity in the
implementation, it pauses asking for reviews once someone has requested
changes (but that matches our branch protection rules anyway).
Because assigning team reviewers requires permissions not available on
the
GITHUB_TOKEN, creating a workflow like this previously would havebeen a bit of a complication but we're now able to leverage the same
GitHub App that we're using for our other workflow automation (without
having to request a PAT).
Now, one might ask “could this be solved by just using a CODEOWNERS
file or passing
team-reviewersto thecreate-pull-requestAction?”And both of those would solve the first issue: the initial
assignment; however, they don’t handle the continuing review requests
to meet the project’s threshold. The same applies to the various other
Actions that exist to auto-assign reviews to pull requests (and many
can’t support the
team_reviewersparameter at all).