We are just moving from another Git-Repo-Hosting-system to Azure DevOps. In the previous system it was possible to restrict who is allowed to complete a pull request (assuming that all findings are resolved). That means the Pull request was "ready" to be merged but only specific people had the permissions to actually execute the merge.
Looking through the documentation of Azure DevOps I have not found such a feature out-of-the-box.
Did I simply miss it or it is not possible at all?
Thank you
Daniel's right. Branch policies already do exactly what you're saying. Policies enforce your team's code quality and change management standards.
You just need to use Require a minimum number of reviewers:
When the required number of reviewers approve the pull request, it can finish.
Also expand with more detail info and show you a example how will this works in your side. Image you have two teams:
Developers:
Patrick
Carl
......
[project]\PM and Developer Managers
PM and Developer Managers:
PM
Developer Managers
One could add the PM and Developer Managers: team as "required" on the branch policy, and keep the Developers team rights to pull requests, allowing other develops to still approve requests and comment etc.
But the request can't be completed until a user in PM and Developer Managers group approves it.
You're looking for branch policies. Branch policies let you designate the circumstances under which a PR can be merged, including required approvers and builds.
Related
Is there anyway in Azure DevOps to forbid people from adding/removing required reviewers when creating a Pull Request?
I have set up the policy "Automatically included reviewers" with a bunch of required reviewers.
But still anyone who create a PR can easily add someone else in the required reviewer list or remove anybody from the automatically included required reviewer.
I want anyone to create a PR but not add/remove any required reviewer.
Apparently this is not possible, and they don't seem to consider it a bug. See this feedback item. I think it is ridiculous that they don't consider this a bug. When you set a branch policy stating: Pull requests to this branch van only be completed when these reviewers have reviewed it, only people having the permission Bypass policies when completing pull requests should be able to complete the pull request without adhering to the policies, which includes the required reviewers policy.
I've added a new feedback item to stress this. Feel free to update this feedback item, however history tells me they will either acknowledge the issue and never fix it, or still deny it is a bug.
We probably will we have to learn to live with this bug
If a required reviewer is added via Automatically included reviewers, the reviewer can't be removed:
For reviewers added manually or via the API there's no way to forbid it as far as I know.
The following feature requests implicitly confirms this:
https://developercommunity.visualstudio.com/t/Users-able-to-change-required-reviewer-t/1196519
When a user hits Resolve on a review comment I made in a PR, I would expect to see a notification in my emails but I do not seem to be getting them.
Here are the options available to me in DevOps:
Here are the options assigned to my user:
For reference, this is the section I'd expect to get updates for when set to Resolved:
I'd imagine it to work similar to how it works in GitHub. Currently I'm relying on team members to #mention me.
I am an employee of an organization. Could it be that the option has been removed from me in some group policy?
Could it be that the option has been removed from me in some group policy?
I am afraid there is no such specific settings to get the notifications for Azure DevOps PR review comment set to resolved.
We could only defined the notification for the Pull request changes. But the default and supported notifications and supported event types do not support to check the state of the PR review comment.
You could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
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.
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 have run into an issue where if my project managers are rushing, they sometimes will help move pull requests along by 'approving' them. As we have set the branch policy to require at least 2 approvals (and the creator cannot be one), this can be a bit of a frustration. I have moved the PMs into a new security group to isolate them from most options but I cannot find anything specific about Pull Requests. Does this just follow under the Contribute option or is there a specific way I can block them from being able to approve pull requests?
They have "Contribute to Pull Request" permissions, located under repo security settings. Remove that permission for the people you don't want to be approving PRs.