A Sneak Peek at the New Mergify

As I wrote a few weeks before, the Mergify team is working hard to bring new functionalities into the product. We conversed with many of our customers those last weeks and did our best to consolidate all the feedback we received into our roadmap.

Now that we’re finalizing the nitty-gritty details of what we called our v2 engine (for version 2, apparently), I think it’s time to give you an overview of what is going to change.

Good Bye Branch Protection

The current engine leverages GitHub branch protection and configures them automatically. This automatic configuration is neat, but it has a few downsides.

First, some users don’t like having Mergify messing with their branch protection. For whatever reason, they might prefer to configure them themselves.

Second, GitHub branch protections only work on a per-branch basis. There’s no way to implement those protections on a per-pull request basis. That’s an issue since we know for sure that many users want finer-grained configuration of their rules.

Mergify leverages branch protections to keep consistent the configured rules and GitHub’s user interface. However, now that we get a better understanding of what users need, branch protection becomes an obstacle. The branch protection is too limited for the wild use case that we want to implement.

The new engine won’t mess anymore with your branch protections.

Hello Checks API

Back in May, GitHub introduced a new Checks API that allows GitHub applications to report more detailed status report. The new Mergify engine now leverages this and communicate better information about what’s going on, which actions will be executed on the pull request, etc.

Welcome Per-Pull Request Rule

As I just wrote, the current engine enforces rules on a per-branch basis. That’s not very flexible, so we had to change that.

The new engine will be entirely based on per-pull request rules. You’ll be able to use a filtering language to select which pull request the actions will be applied to.

For example, to select pull requests that are ready to be merged, you would write something like:

conditions:
  - "#approved-reviews-by>=2"
  - status-success=continuous-integration/travis-ci/pr

The above would match any pull request that has Travis CI passing and being approved by at least two contributors.

You can write conditions based on any pull request attribute. For example, you could match a pull request sent by a bot and apply some particular actions to it:

conditions:
  - author=somebot
  - branch=master
  - status-success=continuous-integration/travis-ci/pr

So let’s talk about actions!

Meet the new Actions

When a pull request matches a rule (using the above conditions), Mergify will execute an action. The actions that will be shipped at launch time will be the ones you already know: merge and backport!

For example, if you wanted to merge using the rebase method any pull request sent on a branch and approved by two collaborators, you can write such a rule:

name: automatic merge after review
conditions:
  - branch=master
  - "#approved-reviews-by>=2"
actions:
  merge:
    method: rebase

If you’re going to automatically merge a pull request from a bot when the CI system passes, without any review, you could write this:

name: automatic merge from myfavoritebot
conditions:
  - author=myfavoritebot
  - status-success=continuous-integration/travis-ci/pr
actions:
  merge:
   method: merge

You can combine the conditions to apply automatic merge to whatever pull request you want.

No need to tell you that we plan to add tons of nifty actions so you can automate more of your workflow. And if you got suggestions, we’re open to hearing them!

This is Awesome. When is That?

Now that we got you excited about all of this, you’re wondering when is it going to be available?

Well, the good news is that it’ll be available starting 15th October 2018. The v1 engine will be kept active until the 31st January 2019. In the meantime, we’ll help our users to migrate to the new system.