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.
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.
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.
I have a public github repo and want to disallow other users to merge into the master branch. They should only be able to create other branches and create pull request. I'm the only one who accept and merge pull requests.
Is this possible with GitHub and if yes, how can I set this up?
Kind regards
By design, all public repositories are read-only when you create them. If you're a member of an organization, you can provide default permissions to do otherwise.
Long and short of it, GitHub does what you wish it to by design.
I have one collaborator in my private github repository. After she sent me a pull request, she could actually go to the pull request screen and executed a merge i.e. she had the privilege to merge her changes into my branch.
Is there some kind of setting that I need to set in order to make sure only I can do the merge? And, I don't think this is because my repo is private, right?
Thanks.
From 'https://help.github.com/articles/defining-the-mergeability-of-pull-requests/':
You can require pull requests to pass a set of checks before they can be merged. For example, you can block pull requests that don't pass status checks. You can also require that pull requests have at least one approved review before they can be merged.
By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. But as your project matures and stabilizes, you can choose to enforce restrictions on how a pull request is merged into your repository.
Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. These branches can also be protected by requiring pull requests to have at least one approved review before they can be merged.
You could use a service like PullApprove or required code reviews to ensure that you have to give permission first.
The "Manage multiple clients" GitHub help page mentions:
This approach lets you retain control over the repos, but still gives your clients access to them.
In many cases it is the cheapest route overall, though you will be stuck paying the bill yourself (unless you bill it to the client).
To use this strategy, upgrade your personal or org account to a paid plan.
Now you can add private repos for the client directly to this account.
If the client wishes to access the repos directly, they can create a free personal account and you can add that user as a collaborator (if the repos are on your personal account) or to a team (if the repos are on an org account).
With an org account you can also give them admin access to the repo if you wish.
So if your project was part of an org account instead of a personal account, you could have the choice the the admin access for the users you add as collaborator.