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 :)
Related
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.
I'm just wondering if there is anyway to restrict who can approve pull requests, or who can be included in on a pull request.
I know you can provide a list of reviewees from a group, or setup auto reviewers... but specifically say people in role x, cannot hit approve or deny on a pull request.
but specifically say people in role x, cannot hit approve or deny on a pull request.
The most direct or best way to restrict approval requests is to add auto reviewers or groups.
If you want to assign this permission to the people in role X instead of adding reviewers or groups, I am afraid Azure devops does not provide a feature to meet this requirement at this moment.
Besides, if anyone in role x but not in the reviewers, the, he approve or rejects PR is not decisive for the final PR completion, it is like a comment:
So, suppose we have such a function, but it is still limited to reviewers.
Hope this helps.
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.
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.
We have a practice in our company that people can't merge their own pull requests. PRs are only allowed to be merged by reviewers.
What can we do on GitHub to enforce this?
Is there some way which would disallow people to merge their own pull request or is there something which will be a good alternative for this policy?
This kind of policy is best managed in GitHub Organizations: it has a richer set of permissions.
You can define teams, and make the reviewer team the owner of the repo which accepts PR.
If you want the reviewer to not accept their own policy, then GitHub permissions wouldn't be enough, and you would need to put in place a listener able to alert you in that case (PR accepted by its author), using GitHub API PR Events.