They use Mergify: Cabal (Haskell)

Here’s a little interview we did with the Mergify bot team to discuss how Cabal maintainers employ the merge bot on our GitHub repository:

tldr; several kinds of mundane tasks like rebases and backports become extremely easy because they require very little human intervention, so you are welcome to try it out too. In the text, we also mention a more sophisticated workflow implemented with the bot; namely, an automatic delay before the merge after all conditions are cleared – we use the delay to make sure most stakeholders had a chance to weigh in.

If you’re curious, our Mergify config is here.

5 Likes

They (we) use Mergify and you can use it too! It’s trivial to set up, good enough, free. I don’t think there are any particular Haskell-specific caveats. I’d venture, the first time you don’t have to manually rebase somebody else’s PR already pays back for the whole setup effort.

2 Likes

Also made good use of mergify to auto-approve and auto-merge dependency bumps, for example. They have a friendly and responsive team.

2 Likes

Indeed, their team is amazing: I asked a couple of random questions on their issue tracker, and they were fast to reply and incredibly helpful.

@nomeata could you share a link to your config doing auto-approves/merges? We haven’t gotten there yet, and I’m curious.

1 Like

Sure, check out the Auto-Approve rules in

2 Likes

What has always bothered me with these merge bots is that you can’t sensibly maintain good GPG signed main branch.

  1. if there’s a rebase involved, the human GPG signatures are dropped
  2. if there is a merge commit involved, you get a machine signature at best
  3. machine signatures don’t convey a lot of trust and defeat the purpose of GPG signing

The only way to keep them is a fast forward merge, which is unlikely to work in most cases.