GitHub Merge Queue

[siggerzz]

Overview

Within the PIE Monorepo we’re fortunate to have a mostly reliable CI setup, and a cadence of change that means we often run into a situation where multiple pull requests are ready to merge into main at the same time.

Currently we enforce Require branches to be up to date before merging for pull requests for a number of reasons:

• Ensuring compatibility with the latest main changes.

• When modifying a component where a change has been merged, we need to ensure any Percy changes are still valid on the open PR.

Problem

Our current set-up usually results in a backlog of PR’s that’re ready to merge, but have to get rebased and have the CI checks run again. While this is valid in some cases, oftentimes it’s needless, especially when open PR’s don’t have a dependency with the last thing that was merged into main.

Solution

GitHub has released Merge Queues to eliminate the need for the Require branches to be up to date before merging check.

Put simply, merge queues allows you to bundle changes under a single, temporary branch to ensure compatibility, operating on a first-in-first-out approach.

The documentation for the various workflow, as well as different success / failure scenarios can be found here

Considerations

While most of our CI infrastructure, should work with this approach, there are a few things to consider:

Preview Deployments

Currently preview deployments get created based on the pull_request event trigger, with the subdomain being derived from the PR number. This would need to be refactored slightly to cater for the merge_group event type, and use a different unique identifier when creating the sub-domain.

Changesets

I don't think this workflow will have an impact on how we use changesets, but I think there are still a few unknowns, specifically around how we would handle Version Packages PRs.

Percy

Currently, i’m unsure on what the process would be for Percy. I believe Percy checks will need to run for the merge queue, but I’m unsure if the usual approve / reject process we follow will cause problems with merge queue.

Other repos such as IBM Carbon have merge queue enabled with features such as Percy, so I may reach out to them at some point to see if they can offer some insight into how their workflow works 👍🏼

I'll continue adding to this as I think of other possible issues, but feel free input if you have any thoughts!

[fernandofranca]

Another recurring issue we might encounter is when the yarn.lock file gets outdated and the next PR to be merged needs to address that. What happens often, is two PRs having the lock file updated, one of them gets merged first and the second needs to be rebase or solve conflicts in order to be on the green and merge, leading to some wasted time and effort.

I'm not sure what exactly causes this issue though.

[siggerzz]

Ah yeah, thanks for this @fernandofranca!

Good point, I think the thing that's causing this is that Version Packages PR's don't currently include the yarn.lock file, meaning subsequent PR's will produce a modified yarn.lock.

Definitely something we need to address, and hopefully just a matter of altering our changesets workflow to run yarn and commit the modified file 👍🏼