They use Mergify: Cabal (Haskell)
Every day, major projects use Mergify to automate their GitHub workflow. Whether they have a core team of 3 or 50 people, the one thing they all have in common is that the project leads are willing to let their developers focus on what’s really important—code. So we decided to meet with some of them to get to know more about the challenges they face and discover how Mergify helps their teams be more efficient when it comes to pull requests. This week, we chatted with Artem Pelenitsyn, who is an active contributor on the Cabal repository for the Haskell programming language.
Please could you explain what Cabal represents within the Haskell project.
Cabal is actually a package manager and build system. It’s a long-standing project that has been around for about 15 years. And thanks to this project Cabal is now the main way to build Haskell software. Before that, developers were just using Makefiles or similar, and the compiler directly. People switched pretty quickly because it is much handier to have a special-purpose build system. There is also a bit of package management, as you would expect, since most modern languages have this ability to fetch stuff from a central repository. It can be GitHub these days, but the main mode of operation is to have one server called Hackage, which stores a lot of Haskell packages. We query it, download things from there, and use them to build.
How many years have you been working on Cabal?
Not long actually! I started contributing at the beginning of 2022. Before that I had been a happy user of Haskell and Cabal for 11 years, mostly for academic and small projects. I decided to help the team out because the development world is changing around us and the build system had to reflect it. So I decided to spend some of my free time on this project. I am now one of the most active people on the Cabal GitHub repository, with approval and merge access.
What GitHub workflow do you apply?
It is a pretty standard one. We have the master branch, which is the latest and greatest version, and then the release branches. So when we want to make a release, we create a branch. We usually maintain two active branches—one for the latest release and one for the upcoming release.
When we review a pull request [PR], we are required to have two approvals to get something merged. When we get the two approvals and the CI is green, we apply a label to the PR to either merge the PR directly to the master branch, or to squash it into one commit and then merge it. In both cases Mergify then merges the PR automatically.
Who can approve PRs?
Our current policy is pretty flexible in terms of giving approval access. Anyone who has contributed meaningfully usually gets access in the hope that they will give back and get more involved in the development. We try to give them a small amount of permissions to make them more involved in the process. This has been the culture and it hasn’t been misused as far as I know. Regarding merge access, there was a period when the Cabal core team were pretty flexible about it, but today maybe only 5 people have it.
What is the volume of PRs that you deal with for the Cabal project?
We don’t have lots of PRs—usually 2 to 4 active PRs per week—so there isn’t much traffic in the repository in terms of features. But we have plenty of issues, as well as discussions on the bug tracker.
What features of Mergify are you using?
The automatic merge based on the two labels I mentioned earlier, as well as commands. The most popular one is “@mergify rebase” and the next is “@mergify backport”.
Also we recently implemented a cool-down period before the merge. Basically, when a PR is ready to be merged we want to allow two more days to see if anyone has any further thoughts or ideas. It was tricky to implement, but with some help from the Mergify team we managed to make it work as intended.
What has been the biggest impact of using Mergify on your team’s performance so far?
The response time has improved significantly!
What would be your #1 tip for someone new to Mergify?
I would say “start small”. You can get a lot of benefits even if you start with very basic configuration. And then see what you want to be improved and search for the documentation.
In preparation for this interview, I looked into the documentation for the squash commit message. We currently use the default setting, which just takes all the commit messages, concatenates them, and puts them as the squash commit message. But while reading the documentation, I discovered that there is another option—you can take the first commit message only, and that’s usually what we want actually, or you can take the description of the PR as the commit message. So when something doesn’t work as expected, you go to the documentation or ask on the issue tracker—this worked well for me.
How would you improve Mergify if you could?
I haven’t had a thorough look but I’m pretty sure I can’t see the merge queues because I don’t have access to the dashboard. They only seem to be visible there, and I can’t work out why as this isn’t sensitive information as far as I can see. So it would be nice if anyone who is interested in what’s happening in the merge queue could have access to that!
