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.
Related
Azure DevOps lets a reviewer tell the developer that they have completed their review with the "waiting for the author" flag on a PR review.
But as the developer how can I tell the reviewer "I have finished addressing comments?" They may get a notification for every reply I make to a review comment but typically, we work that a reviewer won't re-review until I've finished addressing all their comments. I can send them a message but it seems like there should be a way to do it from the PR itself.
Unfortenately there is no out-of-the-box method to do this.
These are the only subscription that can be made for code (git) notification:
You could however come up with a process flow yourself, some examples:
Define that all fixes should be made in one push to the branch. The developer can fix the remark in several commits, but whenever he pushes these commits the notification is send out - triggering the reviewer to look again.
Another option is the agreement of a code word or sentence in the commit message, like: rework-complete.
The reviewer filters out these message in their mail client, to see what PR are up for review again.
Alternatively you could alter the status of a PR linked work item.
For example:
After review, the develop work item is set back to the status: Active.
Whenever this work item is closed, the review can be done again.
This will avoid unwanted, out of AzDo, message sending.
Again, no out-of-the-box solution afaik, but I hope this helps you.
PR authors and reviewers can communicate with each other by adding and responding to PR comments. When you review a PR, use comments to point out issues with the proposed changes, suggest changes, and respond to previous comments. Aim for constructive feedback that's precise and easy to understand. Address recipients directly by using their #username. Reference work items by using #workitemID and other PRs by using !pullrequestID.
Reply to comments
PR authors should reply to comments to let the reviewers know how they're addressing feedback and suggestions:
To reply to a comment, type your response in the Write a reply field. Address recipients directly by using their #username. Reference work items by using #workitemID and other PRs by using !pullrequestID.
After entering your response, select Reply & resolve if your response is final. Otherwise, select Reply.
If you select Reply & resolve, the comment status will change to Resolved. PR authors can also directly change a comment's status, as described in the next section.
Change comment status
New comments initially have an Active status, which PR authors update during PR the review process to indicate how they addressed reviewer feedback and suggestions. PR authors can select a comment status from the status dropdown list:
Active: the default status for new comments.
Pending: the issue in this comment is under review and awaits something else.
Resolved: the issue in this comment is addressed.
Won't fix: the issue in this comment is noted but won't be fixed.
Closed: the discussion in this comment is closed.
When you have finished addressing comments, you can change all the comment status to Resolved and let the reviewers know that you have responded to their suggestions.
You can refer to this document Review and comment on pull requests - Azure Repos | Microsoft Learn.
If you want a feature to highlight that all comments have been addressed in the PR, it's recommended that you could submit a suggestion ticket on Visual Studio Feedback. That will allow you to directly interact with the appropriate engineering team and make it more convenient for the engineering team to collect and categorize your suggestions. By the way, you can directly add your vote after you create the suggestion ticket and keep track of this progress there. Voting helps increase the priority of the issue by consolidating customer impact under one feedback.
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”.
I would like to ask for your help with steps to resolve a seemingly simple issue in regards with branch policies. We have the following requirement: Mandate at least 1 Pull-Request approval from a team member other than the code author. However, once the reviewer has added some comments for minor code changes to be made, and approved the PR, then for the next iteration on this PR we would like to retain the reviewer's previous approval vote so that the code author can complete the PR without waiting for any additional approvals for their latest code changes. We understand that if there are more critical code changes suggested by the reviewer, then they can simply vote to wait or reject the PR.
Could you please help provide steps to achieve this scenario to retain reviewer's approval votes over successive code iteration/s? Thanks.
Assuming you are using Github, do the following
Go to your repository
Click on the settings tab
Click on branches on the left
Edit the branch protection rules
Under "Require a pull request before merging" uncheck the box that says "Dismiss stale pull request approvals when new commits are pushed"
Edit: my bad, completely overlooked the azure devops tag. See if the following works for you
Under Branch Policies, set Require a minimum number of reviewers on, and uncheck the box that says when new changes are pushed.
Found documentation here.
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.
Generally, a Github branch goes to "Approved" state when at least one person approves the changes. But sometimes a branch may be needed to be reviewed by more than one person and it could only be merged when everybody approves.
Is there a way to override default behavior of Github to setup a branch not to go to "Approved" state until all reviewers have approved the changes? Basically I don't want the branch to show up in green until then.
GitHub has the ability to require multiple reviewers.
GitHub does not currently support this functionality.