dhess
commented
2 years ago I set up Mergify on our https://github.com/hackworthltd/hacknix repo, and it's pretty nice. Their "Essential" offering at $10/user/month is not feature-competitive with MergeQueue's $12/user/month "Pro" plan, but it's probably good enough for our needs.
I think I'll switch us over to Mergify in the next week or two.
Our Bors has been down since the holiday, when I made some very big changes to our infrastructure. I'd hoped to have it running again, but haven't had time. Despite this, I do think it serves an important role in our GitHub workflow. I recently discovered that there are commercial Bors-as-a-services, and I'm wondering if now's a good time to switch.
They're both kind of expensive for what they do IMO (several of their plans are comparable to what we pay for Buildkite!), but they're not unreasonable. Bors was reasonably easy for me to manage, but then so were our email servers, Hydra, etc., and I'm quite glad to have converted those to paid services now that we've switched. (Many self-hosted things can be classified as "doesn't take much time to maintain," but it all adds up.)
I think Mergify looks like the more interesting of the two, especially because you can configure it with a
.github/mergify.yamlfile in the repo. MergeQueue requires that you poke around in a UI as far as I can tell. (So basically, Mergify is declarative and MergeQueue is "imperative.")The one thing I saw that is interesting about Merge Queue is something they call ChangeSets, in which you can synchronize PRs across multiple repos. IOW, you tell it to link PR #123 in the primer repo, and PR #456 in the primer-app repo and it will only merge them if both pass CI. I think we are unlikely to couple those 2 projects so tightly — what I'm imagining is that we'll make primer a git submodule of primer-app or something like that (we may not even need to do that, since we're auto-generating the API code that the frontend needs), but I suppose it might come in handy from time to time.
The main issue I see with the change sets feature is that I'm not keen on adding yet another service to our development workflow. All of the other features of these services can be done via their GitHub integration, so I think we will only need to use the MergeQueue/Mergify UIs when we want to monitor progress in detail, or see why a merge failed. Under normal circumstances, you'll probably never need to log in to either of these services.
Anyway, I'm not yet completely sold on the idea of using one of these services instead of Bors, but I am leaning that way.
Interestingly, there was a HN thread about MergeQueue in which the current maintainer of Bors said that he'd stop developing Bors in a heartbeat if GitHub only would add a merge queue feature. All of this does seem like the kind of thing that GitHub should be offering, but don't for some reason. That would also be my ideal scenario, but who knows if/when they'll do it. Bors has been around for awhile and GitHub has yet to accommodate this workflow.