In Github, is it possible to disable the option for users to open pull requests and merge them by themselves?
So that every pull request HAS to be approved by another user.
I believe protected branches offer this.
Go to the repository settings.
Go to "branches"
Choose the target branch you want to protect.
Check "Protect this branch", then require reviews. You can also include repository administrators.
Related
I have a private Github repo which I want to make public, but:
I don't want people to be able to merge their PRs without my approval
I want to be able to merge my own PRs without anyone's approval
Is this possible and how ?
I couldn't find a combination of the above while looking at my repo's settings, unless I pay for a PRO account.
This may not be exact answer, but it should be similar for public repo. I have a private repo and paid account with one additional user license, so I can review and require approval of other user's PRs.
This is how I setup protection. repo -> Settings -> Branches (under code and automation) -> Branch protection rule -> enter a branch pattern (like release*) ..there are number of checkboxes and you want to pick whatever protection you need.
For eg. I picked:
Require a pull request before merging
-- Require approvals
However, found an interesting option which might be useful to you. So if you are administrator you should be able to bypass the protection but other non-admins cannot is what I am gathering
Do not allow bypassing the above settings
The above settings will apply to administrators and custom roles with the "bypass branch protections" permission.
I'd like to automatically (i.e. from Jenkins) merge a GitHub pull request that has been approved by a person and has been tested successfully; in other words, when all THREE of these checkmarks are green:
Is this possible? I haven't found any documentation on an API for GitHub's new "changes approved" code review functionality.
There is a new PullRequestReviewEvent webhook that is triggered when a review is submitted in a non-pending state. The body of the webhook contains the ["review"]["state"] field, which will be approved when all reviewers have approved the changes (i.e. when you get the green "changes approved" tick in the UI).
Combine this with the StatusEvent for the head SHA of your pull request to get the status checks from CI and so on, then finally check the "merge-ability" of the pull by requesting the pull request from the API:
GET /repos/:owner/:repo/pulls/:number
Once you have all three things, you can merge the pull request with:
PUT /repos/:owner/:repo/pulls/:number/merge
and appropriate payload parameters. Note you'll need the Accept: application/vnd.github.polaris-preview+json for some of the payload parameters as they are in a preview period.
Official documentation: "Managing auto-merge for pull requests in your repository".
That is now (Dec. 2020, 4 years later) available:
Pull request auto-merge public beta
Pull request auto-merge is now rolling out as a public beta!
With auto-merge, pull requests can be automatically merged when all requirements for merging are met. No more waiting for long checks to finish just so you can press the merge button!
To use auto-merge, a repository maintainer or admin must first toggle on the repository setting to allow auto-merge (see steps).
Then any user with write permission can enable or disable auto-merge by navigating to the pull request page.
Keep in mind that auto-merge is only available for pull requests targeting a branch with required reviews or required status checks, and therefore is only available on public repositories and private repositories on Team and GitHub Enterprise Cloud plans.
Learn more about pull request auto-merge.
Update Feb. 2021:
Pull request auto-merge is now generally available
With auto-merge, pull requests can be set to merge automatically when all merge requirements are met.
No more waiting on slow CI jobs or tests to finish just so you can click the merge button!
To use auto-merge, first have an administrator allow auto-merge in the repository settings.
Then to enable auto-merge, navigate to the pull request on GitHub.com or GitHub Mobile and tap the button to enable.
Note that auto-merge can only be enabled by users with permission to merge and when there are unsatisfied merge requirements, like missing approvals or failing required status checks.
GraphQL APIs will be rolling out later this week. The pull request webhook event also now includes actions that indicate when auto-merge is enabled or disabled.
Learn more about pull request auto-merge
However, as The Godfather mentions in the comments:
The problem with this is that it doesn't do auto-update.
So as soon as your repo has "branches must be up-to-date" and some other PR got merged, this "auto-merge" doesn't work any more.
It should have been called the same way as Gitlab: "merge when pipeline succeeds", at least it's not as confusing... –
Update Aug. 2021:
Maintainers can now manage the availability of auto-merge in a repository
Maintainers can now manage the repository-level "Allow auto-merge" setting.
This setting, which is off by default, controls whether auto-merge is available on pull requests in the repository.
Previously, only admins could manage this setting.
Additionally, this setting can now by controlled using the "Create a repository" and "Update a repository" REST APIs.
I wrote an app that does this. It responds to the review, labelled, and commit status/checks events, and merges when the merge button is green.
The fact that it merges when the merge button is green means that you can configure the requirements for a mergeable PR in the GitHub settings, there's no need to write separate configuration for the app.
Mergery is:
Free, including for private repositories.
Fast. It's event-driven, it doesn't run on a schedule.
Simple. No configuration required. Just label your PRs with automerge.
You can use Mergify to do exactly this, since this is what it has been created for. Just set up a minimal .mergify.yml file in your repository:
rules:
default:
protection:
required_status_checks:
context:
- continuous-integration/travis/pr
required_pull_request_reviews:
required_approving_review_count: 1
And you'll be good to go.
(disclaimer: I'm one of the Mergify founders)
Using github actions which is one of the new ways, this can be done. I have written a blog about auto approving and auto merging PRs using github actions. However, if the intent is to just merge the PRs only, then then the second job in this work flow would be enough to do it.
https://github.com/bobvanderlinden/probot-auto-merge is a free GitHub app that does the job. It's configurable in .github/auto-merge.yml.
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.
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.
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.