I'm building a service which scans for open pull requests with a specified tag, and merges them automatically if they have been reviewed appropriately.
In some cases, PR's will include changes to files owned by a team in the CODEOWNERS file. To my knowledge, GitHub API has no support for Code Owners.
Is this true? Is there any way to verify whether a PR has been reviewed by a Code Owner? I cannot find any discerning info in the API responses which identify whether or not a review is by a Code Owner or just another user.
Thanks!
Github provides an API for pending reviews, without differentiating whether that reviewer is a CODEOWNER or not.
From what I understand, this service needs to check whether there are pending reviews on the PR, so in this case it doesn't matter if its a codeowner or not, because your call to github API reviews will return that there are indeed pending reviews.
Another tool you can use is codeowners-api which can help you understand map whether the reviewers on a PR are indeed CODEOWNERS
Disclaimer - I wrote the library
Related
Upon reviewing the branch protection settings for a GitHub repo, and reading the documentation for all of the settings, I still can't quite figure out the difference between enabling these two groups of settings:
According to the documentation, if I require approvals, it means an approval is required from someone else (I cannot approve my own PR):
If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.
The next option seems self explanatory, but here is what the documentation has to say about it:
Optionally, you can choose to dismiss stale pull request approvals when commits are pushed. If anyone pushes a commit that modifies code to an approved pull request, the approval will be dismissed, and the pull request cannot be merged. This doesn't apply if the collaborator pushes commits that don't modify code, like merging the base branch into the pull request's branch.
However, when I look at the documentation for the branch protection setting to "require approval of the most recent push", it sounds like it does the same thing as if I had the first two enabled:
Optionally, you can require approvals from someone other than the last person to push to a branch before a pull request can be merged. This ensures more than one person sees pull requests in their final state before they are merged into a protected branch. If you enable this feature, the most recent user to push their changes will need an approval regardless of the required approvals branch protection. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement.
It sounds like this option implies that an approval will be dismissed if a new commit is pushed to the branch for the open PR. If that's the case, then isn't enabling the first to the same as enabling the last one?
The "require approval of the most recent push" protection rule was recently introduced (oct 2022), with the express purpose to prevent someone responding to a code review request from sneaking in changes and approving them themselves or using the already supplied approval from another reviewer.
The security research that explores these topics has not been broadly published, but there are some great discussions with recommendations on how to secure your branches.
With this new policy enabled, when a reviewer applies some suggestions to the code, they can't approve and merge the code without finding another person to review their changes.
Excerpts from the article, red team, emphasis mine:
— Modify code after review
After the attacker submits a valid and good code change that is approved, the attacker abuses their existing approval to make further changes that include bad code while retaining the stale approval.
Another scenario is that the attacker could first be a good samaritan and approve the code of a fellow developer, let’s assume it’s a good code change, but it doesn’t matter. What matters is that once they have approved that pull request, they could abuse their own write access, add bad code and self-approve their own code change.
And the protections, blue team, emphasis mine:
Require a pull request before merging
Require approvals
Dismiss stale pull request approvals when new commits are pushed
Require review from Code Owners
Allow specified actors to bypass required pull requests (avoid unless you absolutely need to)
Require approval of the most recent push (this is a new setting, as of October 2022, and is really great mitigation for some of our attack scenarios)
Require status checks to pass before merging (it you have some form of CI with tests, linters, SAST, it would be great to enforce those)
Require signed commits (this is great for end-to-end accountability)
Enforce Branch Protection for administrator (i.e. “Do not allow bypassing the above settings”)
Recommended mitigations, emphasis mine:
— Modify code after review
Attacker submits good code, gets approval, then submits bad code
The mitigation is to set your Branch Protection to “Dismiss stale pull request approvals when new commits are pushed”.
Attacker approves someone else’s good code, then submits bad code and self-approves changes
The mitigation is to set your Branch Protection to “Require approval of the most recent push”.
This is what I know so far from my understanding of Github:
Github allows default reviewers whether it be for a specific type of file in any/certain location through the creation of the CODEOWNERS file.
Github allows the number of reviewers that are required to approve a PR. You can also specify what type of access they have.
Github allows required review from Code Owners
What I want to know is if there is a way to set up mandatory reviewers meaning that the PR can't get merged until certain people give their approval.
For example, I created a PR and I have reviewers A, B, C, D, E, and F. I want to make it so that this PR cannot get merged until reviewers A and B have approved it. I thought I could use the Require review from Code Owners but I think that it only requires at least one person to approve. The other idea that came to mind was just setting the required approval to the same number of people inside the code owners. Any help would be much appreciated.
I thought I could use the Require review from Code Owners but I think that it only requires at least one person to approve.
Your assumption is right. Currently, you can request multiple owners to review a PR, but only one of the reviews will be mandatory.
You can check the accepted answer in this GitHub Community discussion for more details.
As for the second part of your question,
setting the required approval to the same number of people inside the code owners
I believe that should do the trick. You may also want to follow the tip, described in the Approving a pull request with required reviews and ensure that code owners are the only persons with write permissions to the repo so that no other persons or groups will mess up the review process:
If your repository requires approving reviews from people with write or admin permissions, then any approvals from people with these permissions are denoted with a green check mark, and approvals from people without these permissions have a gray check mark. Approvals with a gray check mark do not affect whether the pull request can be merged.
On my organisation we use Azure DevOps and we have a repository where we want developers to be able to create pull requests with changes to it, but only develpers belonging to certain AD group to be able to approve them. What's the best way to achieve this in Azure DevOps?
According to Microsoft Documentation there is a permission called "Contribute to pull requests " which allows "Can create, comment on, and vote on pull requests." However, disabling this would mean that people cannot create pull requests. I want them to be able to create the pull request, just not able to approve them and complete them.
However, disabling this would mean that people cannot create pull
requests. I want them to be able to create the pull request, just not
able to approve them and complete them.
If the Contribute is set to Deny, then the developer can review the code/create new branch/create PR/approve PR but can't push changes to master branch or branch not created by himself/complete PR. So this option can only partly meet your needs.
Apart from above, a most recommended way in this scenario is to use Branch Policies.
Since the original purpose is to avoid developers to complete the PR themselves, you can set both Require a minimum number of reviewers and Automatically Include reviewers options to meet your original needs:
So that all the PRs in master branch can't be completed until it gets enough approvals from specific Group. (The group you're in, Project Administrators or what) Then the developers can create the PR, but the PR can only be completed by approvals from you(Team admins/managers?).
You can choose one of the above two options or combine them together to meet your needs.
In addition: If all above still can't meet your requirements very well, feel free to post your feature request in our User Voice forum, the Product Team would consider about your feedback. Follow the feedback and you can get notifications if there's any update.
Hope all above helps :)
I am developing an automation tool that deals with GitHub pull requests and need to find the full list of GitHub pull request review statuses but couldn't get that either on its own API documentation page or generally on the web.
Those I've already found include APPROVED, CHANGES_REQUESTED, PENDING and DISMISSED. Appreciate if someone can provide me the full list.
This refers to GitHub Enterprise version of 2.12.
Check the list of available statuses in GraphQL API docs. There is the link. I'm pretty sure that other APIs (for instance, REST) also support and provide the same list.
There is a snippet from the documentation:
PullRequestReviewState
The possible states of a pull request review. Values
APPROVED
A review allowing the pull request to merge.
CHANGES_REQUESTED
A review blocking the pull request from merging.
COMMENTED
An informational review.
DISMISSED
A review that has been dismissed.
PENDING
A review that has not yet been submitted.
A feature added on Dec, 7, 2016, announced on GitHub blog, introduced the option to add reviewers to a Pull Request
You can now request a review explicitly from collaborators, making it easier to specify who you'd like to review your pull request.
You can also see a list of people who you are awaiting review from in the pull request page sidebar, as well as the status of reviews from those who have already left them.
However, explicit setting a reviewer for a PR was already done by assigning people (assignees option).
With both options now available, what's the role of each option since they both share the same end goal?
EDIT:
After discussing with several OSS maintainers, reviewers is defined as what the word supposed to be: to review (someone's code) and "assignee" has a looser definiton explained below.
For "reviewer": someone you want to review the code. Not necessarily the person responsible for that area or responsible for merging the commit. Can be someone who worked on that chunk of code before, as GitHub auto-suggests.
For "assignee": up to the project's team/maintainer what it means and there's no strict definition. It can be the PR opener, or someone responsible for that area (who is going to accept the PR after the review is done or just close it). It's not up to GitHub to define what it is leaving it open for project maintainers what fits best for their project.
Previous answer:
Ok I'll go ahead and answer my own question.
For PR of users with write-access: the Assignee would be the same person who opened the PR, and reviewer would replace the old assignee function (reviewing code), being this one someone of assignee choice.
For PR of users without write-access (outside contributors): Someone with write-access would assign herself (or other write-priviledge member), to review the PR (Reviewer). Assignee is blank.
For unfinished PR from outside contributors: the write-access member would take the unfinished work and assign for her. She will be responsible for finishing the task, being the Assignee. Since the main reason of PRs is reviewing changes, she would select some other people to review the changes.
In GitHub a reviewer is a person who reviews the pull request. A project owner can request review from any of the maintainers, They can even set an option so that the pull request can be merged only if it is reviewed by one of the maintainer with write access.
According to official github documentation, Assignee is a person who is working on specific issues and pull requests. It is sometimes confused as a reviewer. It is actually meant to be used with issues rather than pull request so that when we receive a issue we can assign someone to fix it. In a pull request, an assignee refers to a person who's in charge of merging that pull request after getting comments and change requests from other maintainers.
As per accepted answer. Yes, "assignee" has a looser definition and can be used differently to suit a teams need.
In our team of 8 devs, in most PRs we have 1 reviewer, who suggests changes and ultimately approves the PR. During review phase, "assignee" is the person who opened the PR; later on if PR is picked up by other developer, a new "assignee" is added. Once PR is approved and ready for QA or direct merge, a new QA "assignee" is added. This way "assignee" list grows.
We use "assignee" to designate following people collectively:
Pull Request Author
Author working on PR change suggestions (usually same as 1)
QA person involved
Person responsible to merge (usually same as 2 or 3)
Using "assignee" helps locating the PR in future easily. One of my project has >3000 PRs.
is:open is:pr author:raya-dumas
is:closed is:pr assignee:raya-dumas
Or just author:raya-dumas to find all items author created (issues, PRs)
and other similar queries to ease the search process. "milestones" are quite helpful to use as well to ease PR search.
The biggest difference between "reviewers" and "assignees" is that reviewers actually have a tracked state according to GitHub -- did they review the PR yet or not?
When you add a reviewer, what it actually does is create a "review request":
The reviewer gets notified (like an "assignee" would) but now they actually have a task they can complete, which is to provide a "review" on a pull request:
After the reviewer leaves a review (approving or requesting changes), that information is tracked in the GitHub API and interface:
With assignees, you can associate people with a PR but beyond that GitHub doesn't really care what that means or what those people need to do. With reviewers, you can use new search queries, "protect" branches, assign reviewers with CODEOWNERS, and build deeper API integrations around review assignment and workflows manually or through tools like PullApprove.
Before GitHub only had an assignee field and no reviewer field. There was no distinction back then so the assignee field was most commonly used as a reviewer field.
But use them whatever way suits your project.
Another difference: the person who created the PR can assign himself/herself as the assignee, however cannot request himself/herself as one of the reviewers.