Improving the backport workflow

We spent quite a lot of time maintaining software in the past, with multiple stable branches. When a bug fix is committed in your development branch, you then need to copy it to your stable branches where the bug is present.

This is why one of the first features we implemented in our engine is the backport action.

In most cases, copying a bug fix from one branch to another can be done automatically. That’s why we automated the action with Mergify so that you can trigger a backport of a pull request routinely.

We see many open-source projects having this workflow embracing Mergify because of that. It’s a huge time saver.

Limitations

There can be a few hiccups when doing backports, the most common one being conflicts. A bug fix in your master branch might not apply cleanly to your stable branch and then git complains about the code conflicting.

Our engine is not smart enough (yet) to fix those for you, though it could do a better job.

New Features

We added two features last week that improved the behavior when backporting pull requests.

First, Mergify will not create a pull request with conflicting data if the cherry-picking of the commits fail. Instead, it will signal that creating the pull request failed in the check result. This should prevent creating pull requests which have no more value than what a human would do.

This behavior is overridable via the ignore_conflicts configuration setting and setting it to true.

Then, in the case you’d prefer to ignore conflicts, Mergify will create the pull request with the conflicting code inside, but will now add a label to identify it. The default label name is conflicts, but you can configure it with the label_conflicts setting.

Being able to identify conflicting backports was a long-awaited feature. It will allow maintainers to automatically merge non-conflicting backports when their CI validates them — without any human intervention.

We hope that’ll make life easier for all our maintainers out there!