Skip to content
A GitHub App built with Probot that automatically merges pull requests
TypeScript Other
Branch: master
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github Remove FUNDING.yml Aug 26, 2019
.vscode initial commit Jul 12, 2018
src work around graphql query incorrect type signature Aug 21, 2019
test
.dockerignore Add Dockerfile and build scripts Apr 25, 2019
.editorconfig add editorconfig Jul 14, 2018
.env.example remove WEBHOOK_PROXY_URL from .env.example Jul 15, 2018
.envrc add direnv and nix shell file Dec 5, 2018
.gitignore ignore visual studio code files Nov 23, 2018
.hound.yml add hound configuration Aug 27, 2018
.travis.yml travis: update condition Jan 19, 2019
CODE_OF_CONDUCT.md initial commit Jul 12, 2018
CONTRIBUTING.md initial commit Jul 12, 2018
Dockerfile Add Dockerfile and build scripts Apr 25, 2019
LICENSE initial commit Jul 12, 2018
README.md Add Dockerfile and build scripts Apr 25, 2019
apollo.config.js fix linting errors Nov 27, 2018
auto-merge.example.yml Fix the Github link Jul 17, 2019
codecov.yml
package-lock.json Bump standard from 14.2.0 to 14.3.0 Sep 14, 2019
package.json add dotenv to dependencies Aug 21, 2019
query.graphql use check databaseId instead of id Apr 28, 2019
schema.json remove MergeStateStatus preview Nov 27, 2018
shell.nix nix: use shell helper function May 5, 2019
tsconfig.json do not include test in tsconfig Aug 27, 2018
tslint.json add tslint configuration Aug 11, 2018

README.md

probot-auto-merge

Travis CI Coverage

A GitHub App built with Probot that automatically merges PRs

Probot Auto Merge in action

Usage

  1. Configure the GitHub App
  2. Create .github/auto-merge.yml in your repository.
  3. Customize configuration to your needs. See below.

Configuration

Configuration of probot-auto-merge is done through .github/auto-merge.yml in your repository. An example of this file can be found here. You can also see the configuration for this repository here.

The configuration has values that serve as conditions on whether or not a pull request should be automatically merged and also configuration about the merge itself. Values that serve as conditions are annotated as such below.

All conditions must be met before a PR will be automatically merged. You can get more flexibility by defining multiple rules. Rules can have multiple conditions and if any of the conditions inside a rule are met, the PR is also merged. See rules.

Note that the default configuration options are to do nothing. This is to prevent impicit and possibly unintended behavior.

The configuration fields are as follows:

minApprovals (required, condition)

The minimum number of reviews from each association that approve the pull request before doing an automatic merge. For more information about associations see: https://developer.github.com/v4/enum/commentauthorassociation/

Possible associations: OWNER, MEMBER, COLLABORATOR, CONTRIBUTOR, FIRST_TIMER, FIRST_TIME_CONTRIBUTOR, NONE

In the example below when a pull request gets 2 approvals from owners, members or collaborators, the automatic merge will continue.

minApprovals:
  COLLABORATOR: 2

In the example below when a pull request gets 1 approval from an owner OR 2 approvals from members, the automatic merge will continue.

minApprovals:
  OWNER: 1
  MEMBER: 2

maxRequestedChanges (condition, default: none)

Similar to minApprovals, maxRequestedChanges determines the maximum number of requested changes before a pull request will be blocked from being automatically merged.

It yet again allows you to configure this per association.

Note that maxRequestedChanges takes presedence over minApprovals.

In the example below, automatic merges will be blocked when one of the owners, members or collaborators has requested changes.

maxRequestedChanges:
  COLLABORATOR: 0

In the example below, automatic merges will be blocked when the owner has requested changes or two members, collaborators or other users have requested changes.

maxRequestedChanges:
  OWNER: 0
  NONE: 1

The default for this value is:

maxRequestedChanges:
  NONE: 0

blockingLabels (condition, default: none)

Blocking labels are the labels that can be attached to a pull request to make sure the pull request is not being merged automatically.

In the example below, pull requests that have the blocked label will not be merged automatically.

blockingLabels:
- blocked

Note: remove the whole section when you're not using blocking labels.

requiredLabels (condition, default: none)

Whenever required labels are configured, pull requests will only be automatically merged whenever all of these labels are attached to a pull request.

In the example below, pull requests need to have the label merge before they will be automatically merged.

requiredLabels:
- merge

Note: remove the whole section when you're not using required labels.

blockingTitleRegex (condition, default: none)

Whenever a blocking title regular expression is configured, pull requests that have a title matching the configured expression will not be automatically merged.

This is useful whenever pull requests with WIP in their title need to be skipped.

In the example below, pull requests with the word wip in the title will not be automatically merged. This also includes [wip], WIP or [WIP], but not swiping:

blockingTitleRegex: '\bWIP\b'

reportStatus (default: false)

The status of the auto-merge process will be shown in each PR as a check. This can be especially useful to find out why a PR is not being merged automatically.

To enable status reporting, add the following to your configuration:

reportStatus: true

updateBranch (default: false)

Whether an out-of-date pull request is automatically updated. It does so by merging its base on top of the head of the pull request. This is similar to the behavior of the 'Update branch' button.

`updateBranch`` is useful for repositories where protected branches are used and the option Require branches to be up to date before merging is enabled.

Note that this only works when the branch of the pull request resides in the same repository as the pull request itself.

In the example below automatic updating of branches is enabled:

updateBranch: true

deleteBranchAfterMerge (default: false)

Whether the pull request branch is automatically deleted. This is the equivalent of clicking the 'Delete branch' button shown on merged pull requests.

Note that this only works when the branch of the pull request resides in the same repository as the pull request itself.

In the example below automatic deletion of pull request branches is enabled:

deleteBranchAfterMerge: true

mergeMethod (default: merge)

In what way a pull request is merged. This can be:

  • merge: creates a merge commit, combining the commits from the pull request on top of the base of the pull request (default)
  • rebase: places the commits from the pull request individually on top of the base of the pull request
  • squash: combines all changes from the pull request into a single commit and places the commit on top of the base of the pull request

For more information see https://help.github.com/articles/about-pull-request-merges/

mergeMethod: merge

rules (default: none)

Rules allow more flexiblity configuring conditions for automatically merging. Each rule is defined by multiple conditions. All conditions inside a rule must be met before a rule triggers a merge. Any of the defined rules can trigger a merge individually.

An example of a configuration with 2 rules that will trigger a merge upon 1 approval from an owner or a merge label:

rules:
- minApprovals:
    OWNER: 1
- requiredLabels:
    - merge

This can be combined with conditions on global level, as the global conditions will take presedence. The following example will not trigger a merge when a PR has the blocking label, regardless what the rules say:

blockingLabels:
- blocking
rules:
- minApprovals:
    OWNER: 1
- requiredLabels:
    - merge

Note: remove the whole rules section when you're not using any rules.

Development

Setup

# Install dependencies
npm install

# Run typescript
npm run build

Testing

npm run test

or during development:

npm run test:watch

Running

See https://probot.github.io/docs/development/#configuring-a-github-app

npm run build && npm run dev

Running on Docker

This will build and run the app on a container called probot-auto-merge:

npm run docker

To just build the container image:

npm run docker:build

To run the built image:

npm run docker:run

Contributing

If you have suggestions for how probot-auto-merge could be improved, or want to report a bug, open an issue! We'd love all and any contributions.

For more, check out the Contributing Guide.

License

ISC © 2018 Bob van der Linden bobvanderlinden@gmail.com (https://github.com/bobvanderlinden/probot-auto-merge)

You can’t perform that action at this time.