We are working with Azure Devops, merge into main only via PR.
If the QA team reject the PR because of some bug in the code, and the developer fixed the bug - do we have to open a new PR?
Can we not update the code on the current PR and re-submit it?
Thank you.
Rejecting a PR is a vote on PR changes
It odes not prevent you to push additional commits on it, requesting for a feedback reset, and a new vote.
You can use a branch policy:
To reset votes whenever a PR author pushes new changes, select Reset code reviewer votes when there are new changes in the Require a minimum number of reviewers branch policy.
Related
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.
I'm trying to find a way to stop users who have worked on a branch (who have committed changes on a branch) form being able to approve in a pull request on that branch. The idea that a dev can't approve their own work.
I haven't been able to find anything in the devops documentation and was hoping someone might have found a way that I've missed.
Anyone come across a solution?
Out of the box, you can prevent the creator of the pull request and the most recent pusher from approving their own changes, but you can't prevent every user who's committed to the branch from approving their changes. You likely won't want to prevent every developer who's committed to a branch from approving, because eventually, that will be nearly the entire development team.
You'll want to head to Project Settings > Repositories > Policies and update your branch policy to adjust the following settings:
Unchecked: Allow requestors to approve their own changes
Checked: Prohibit the most recent pusher from approving their own changes
Here's Microsoft's documentation on how to enable approval restrictions:
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#require-a-minimum-number-of-reviewers
The feature Prohibit the most recent pusher from approving their own changes just prohibit the pull request creator from approving their own changes.
For example, user A create branch and push commit, then user B create the pull request.
The user B can vote Approve but the vote will not count toward the Minimum number of reviewers. And user A vote approve the pull request and the vote will count toward the Minimum number of reviewers
Prevent a user approving request if they have worked on the branch
You could add your request for this feature on our UserVoice site, which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
In addition, as a workaround, we could configure the branch policy and enable the feature Automatically included reviewers-> add admin as request reviewer and set the option Policy requirement to Required. Then after the administrator checks and approves the pull request, then developers can complete the pull request.
Also, If there are fewer developers, we can let each developer create his own branch, they can only work on their own branch and create pull request for their own branch, then enable the branch policy Prohibit the most recent pusher from approving their own changes to do this.
As far as I could find Azure DevOps only allows to review Pull Requests by Update on the PR. I can't find any way to review the commits in the PR such that I could review the commits one by one and have comments showing up in the PR. If I simply leave a comment on a commit, it's a global comment in the repository. Does anyone know of a way to review the commits one by one?
You could see the commits for a PR in link https://dev.azure.com/{org}/Git/_git/Git/pullrequest/{id}?_a=commits, but the comments you add in the commit won't show on the Overview of a PR, you have to click into the commit and check the comments.
I'm not sure if this is an appropriate question for SO but say I make a PR in Github and the reviewers of the PR request changes before it is merged. When I subsequently commit the requested changes on my branch that I am trying to merge are the reviewers notified that I have made the change? Or do I need to explicitly comment on the PR that I have made the change and tag the reviews?
When I subsequently commit the requested changes on my branch that I am trying to merge are the reviewers notified that I have made the change?
They will be able to see/notified you made a new commit, but they won't know if it addresses the PR concerns (or if you're simply adding unrelated changes). Best practice is to comment on the PR and tell them you made changes - tagging the reviewer(s) definitely won't hurt!
Since February 2019, no need to comment: you can Re-request review on a pull request
If changes have been made to a pull request that has already been reviewed, you can now re-request a review with a single click in the pull request’s sidebar. This will notify the requested reviewers that changes have been made.
I have a PR that has been submitted that I have requested small updates/ changes to be made to. The user has switched GitHub profiles during the time the PR was open to the time I reviewed the PR. He now wants to be able to submit the changes to the PR as his new username. Is there a way to give the new user write access to the PR?
Here is a link to the PR for reference.