The Ops Community ⚙️

Cover image for Using GitHub's pull request merge queue in your CI pipelines

Using GitHub's pull request merge queue in your CI pipelines

There's been quite an audible buzz of excitement about GitHub's pull request merge queues from our users recently. The merge queue pattern increases the efficiency and stability of software delivery workflows by automatically handling pull request merges into your busiest target branches. Merge queues ensure that pull requests get merged in the correct order, and significantly reduce CI workloads, and potential delivery blockers.

Prior to merge queue, merging pull requests into main involved:

  • Merging main into the pull request branch, so changes wouldn’t break main when merged
  • Kicking off a build in CI (for these newly pulled and merged changes)
  • Discovering another PR was merged before the build finished
  • Rinse and repeat 🌀😵‍💫
  • Finally merging the PR into main

The endless cycle that is main branch diverging from the version in your pull request branch :(

I’d often be rushing to get my PR merged before someone else snuck theirs through, or I’d forget to pull the latest changes from main into my feature branch before pushing to main. Often, my PR merge would fail, because it wasn’t in sync with the main branch. I saw red–quite literally.

Merge queues automatically build pull request branches with the most recent change (or PR) to be merged ahead of it in the queue. 🙌

GitHub's pull request merge queue automatically builds PRs with the previous commit in the queue.

The merge queue isn’t new – Uber and Shopify have been using them for close to five years in their pipelines in order maintain high throughput and low commit turnaround time on their busy main branches (think thousands of merges to main per day!). If you have lots of contributors, and high volume of pull requests going to main and if you have frequent flaky merges blocking subsequent commits and creating a backlog of builds, you might find pull request merge queue to be a useful tool,as it minimizes merges tripping over each other on the way to main. There’s some good news if you’re a GitHub Enterprise or open source organization, because you can easily play with it now too: merge queue is now available in public beta.

Using merge queue in your Buildkite pipelines

Include the gh-readonly-queue/{base_branch}/* filter pattern in Pipeline Settings → GitHub → Branch Limiting.

Displays the branch filter pattern that's found in the branch limiting setting

Check the newly-released “Skip builds with existing commits” checkbox in your Pipeline Settings → GitHub → GitHub Settings. This will ensure that you will no longer kick off any unnecessary builds (because there's a green build on the commit ahead of your PR in the merge queue). 🤯

Check the new "skip builds with existing commits" checkbox in your pipeline GitHub settings.

The efficiency merge queue offers is exciting, though you should keep in mind:

  • This is an experimental feature and GitHub has flagged that it’s likely to change
  • Configuring branch protection and required checks don’t currently work, and are on our radar in the next couple of months

There's more about how to use it in the Buildkite docs, you can obviously also use merge queue in GitHub Actions, and in some other CI/CD providers, so go try merge queues out – I'd love to hear what you think!

Oldest comments (0)