From now on, we’d like to share with you a summary of everything that happened during the last quarter of Mergify.
This is a good way for you to get informed about new and exciting features, while a great exercise for us to reflect back on our progress!
New Assign Action
What’s better to assign a pull request to a colleague? I’ll tell you: doing it automatically.
This is now possible, thanks to the new
Fun fact: this was implemented by one of our long-time user Eric, so kudos to him for working on that!
New Request Reviews Action
It seems that Eric is unstoppable and on his way to automate his whole company. 🙀 He also implemented the request_reviews action that allows requesting a review from your dearest coworker.
That sounds really handy when you need to automatically request reviews based on modified files, labels, pull request authors, etc:
- name: request review for John (mentor) from Martin (trainee)
New Configuration File Location
Some of our users had a request to move the
.mergify.yml out of the root directory of their repository. It’s now possible to name that file
New Status Neutral Condition
Some GitHub checks might report a status that is neutral — rather than failure or success. Mergify now exposes check-neutral in the conditions, so you can write rules based on this.
New Delete Head Branch Force Option
delete_head_branch action was being used, it would delete the head branch no matter what. This was a problem for many users whose head branch might be a target of other pull requests: those pull requests would automatically get closed by GitHub!
From now on, the
delete_head_branch does not delete those head branches if they are being used, unless you use the force parameter.
Better Branch Protection Compatibility
GitHub finally fixed one of the flaw of the branch protection mechanism: you were not allowed to put a GitHub Application in the authorized list of users authorized to merge. This is now possible and you can use this feature and gives Mergify (and only Mergify if you wish!) the right to merge.
Custom Merge Commit Message
One merging a pull request, it’s sometimes desirable to customize the merge message. This is possible when using the GitHub user interface, but it was not accessible when using Mergify merge action.
The merge action will now read the pull request body to look for a section named Commit Message. It will use this as the merge commit message if available.
Detecting Conflicting Pull Requests
The conditions system now exposes a new attribute for pull requests: conflict. This is true whenever a pull request is marked as being in conflict by GitHub.
Our master piece is now online. Dubbed Simulator, it allows you to test your rules on your pull requests before merging them in your configuration file.
The simulator is accessible from your dashboard.
That’s it for this last quarter. We hope you’ll enjoy those new features and will come up with new fancy automation for your workflows! If you have any new ideas or feedback, feel free to reach us!