[jes5199]

I don't know what it's like now, but GitHub's internal merge queue circa 2017 was a nightmare. Every PR required you to set aside a full day of babysitting to get it getting merged/deployed - there were too many nondeterministic steps.

You'd join the queue, and then you'd have to wait for like 12 other people in front of you who would each spend up to a couple hours trying to get their merge branch to go green so it could go out. You couldn't really look away because it could be your turn out of nowhere - and you had to react to it like being on call, because the whole deployment process was frozen until your turn ended. Often that meant just clicking "retry" on parts of the CI process, but it was complicated, there were dependencies between sections of tests.

[rufo]

It got a little bit better, first with trains (bundling together PRs so they weren't going out one at a time), and then the merge queue started automating most of the testing and fitting together PRs into bundles that could go out together. But by the time I left GH last year it had devolved into roughly the same amount of hassle; I had multiple days where I could queue a PR for deploy mid-morning and not have the deploy containing it go out until dinnertime, and I'd need to keep an eye out in Slack in case merge or test conflicts arose.

[mattmatheson]

How did you guys resolve merge or test conflicts? Did you just have to rebase, update your PR, and resubmit?

[jes5199]

well, that’s horrifying! I appreciate the update though