Pull Request Merge Queue Public Beta Feedback

[willsmythe]

We want to hear from you on how we can improve pull request merge queue, now in public beta for repos on GitHub Enterprise Cloud and open source organizations! 🎉 See the changelog for more details.

Let us know how we can make the feature work better for you!

👉 Important: configuring your CI

Before enabling merge queue for a branch, make sure your CI is configured to build the temporary branches created by the queue. This is the most common problem we're seeing.

For GitHub Actions, add merge_group as a trigger (under on) to ensure this workflow is run for queue-created branches

For other CI services, you may need to update your branch filters or triggers to build branches starting with the prefix gh-readonly-queue/{base_branch}/

See the docs for more details.

🐛 Known issues

Some of the more common or noteworthy issues we are tracking:

• Actions workflows not triggering on merge_group (fixed)
• @depdendabot merge command does not working (Dependabot team is evaluating)

🚀 Top feature requests

• API to enqueue/dequeue and view queue
• Require different status checks for a PR's entry into the queue vs. for merging by the queue

[mayank99]

One thing I noticed immediately is that when clicking on "Merge when ready", it doesn't allow specifying the commit message/description.

This can be alleviated to an extent by changing the default commit message to use the PR title/description, but that's not ideal.

[magicus]

We have tried using merge queues, and moved off them again, simply because this functionality was missing. We tried enabling them again right now, hoping this would have been fixed, but alas, it had not, so we had to disable them again. :-(

To me, this is the single biggest outage in the merge queue functionality. Please prioritize implementing it. And perhaps ping this thread when it's done..? 😍

[jasongornall-dd]

Any updates on support for this?

[xun-guo-anzx]

Would be good if merge queue can make customised auto-merge commit message set up via API: https://docs.github.com/en/graphql/reference/mutations#enablepullrequestautomerge to persist.

[dsmith3197]

My team is also waiting for this functionality. In the meantime, we have been using the PR title/description as a workaround.

One undesirable behavior we noticed is that markdown comments (e.g., from a PR template) are included in the commit message. From a UX point of view, I would personally expect the commit message to be the same as the visible PR description. Do you agree, and if so, is this something that we can change?

[sandstrom]

@willsmythe Great with the queue reaching public beta!

I've written some feedback on the Merge Queue a while back, when we tested it in the private beta. Didn't work for us (for the reasons mentioned in my feedback).

Awesome if you'd like to take a quick look and respond:

• Merge Queue Feedback: Support for semi-linear merge #14863

(in short, we want the queue to support a semi-linear history, something which e.g. AzureDevOps support, see https://devblogs.microsoft.com/devops/pull-requests-with-rebase/#semi-linear-merge)

---

While I have your attention, I'd also love to hear your thoughts on these two:

• Intelligent 'Dismiss stale approvals when new commits are pushed' #12876
• Support semi-linear history (rebase && merge --no-ff) #8940

(also related to PR workflow)

[kaste]

Ah, sh**, thought merge-queue is the semi-linear strategy on GitHub. 😄

[sandstrom]

@willsmythe Great, thanks! 🏅

Semi-linear merge support (in general, and in the queue) would make our team workflow that much better on Github 😄

---

For reference, this functionality also exist in Gitlab, illustrated as follows:

https://docs.gitlab.com/ee/user/project/merge_requests/methods/#merge-commit-with-semi-linear-history

[sandstrom]

@willsmythe Just checking in on this one, do you have any update on semi-linear merge support?

We'd love to start using the merge queue, but lack of semi-linear merge is a blocker for us.

I know semi-linear merges are supported in Gitlab, Azure Devops and Bitbucket. So I'm hoping Github would add support too 😄

[sandstrom]

@willsmythe Happy autumn! 🍂

Just wanted to check in to hear if you have any updates on semi-linear merge support?

[sandstrom]

Happy New Year! 🎆

Just checking in to see if there are any planned support for semi-linear merge?

That's the missing piece before we can start using the merge queue functionality.

[Methuselah96]

I'm trying out this feature in a sample repo, but the merge_group event never gets triggered for GitHub Action CI. The PRs just remain in the queue and never get merged. Any suggestions on what I'm missing?

[dogmatic69]

I've been trying to make queues work and have tried every combination of merge_group, pull_request_target and pull_request. Nothing got the jobs running...

Digging through here I saw that workaround for push with branches matching gh-readonly-queue/master/** and finally I get something happening.

Is there a regression to this issue?

[alex-statsig]

Our triggers are:

  push:
    branches: [main]
  pull_request:
    branches: [main]
  merge_group:
    branches: [main]

And this works fine for me. Only issue I've had is that the paths filtering is not available for merge_group. We were using the push approach a while back but started having issues with that (two PRs entering at the same time caused issues).

[dogmatic69]

which one is actually triggering it though? For me I could only make it happen with push. the queue does not create a PR so it should never trigger on pull_request.

merge_group, pull_request and pull_request_target did not trigger anything for me.

[scarf005]

can confirm this is still happening. workflow trigger used:

on:
  push:
    branches:
      - upload
    paths-ignore:
      - doc/**
      - 'scripts/**'
  merge_group:
  pull_request:
    branches:
      - upload
    paths-ignore:
      - doc/**
      - 'scripts/**'

[snowystinger]

I am not seeing the merge_group.checks_requested in "Recent deliveries" under webhooks. I assume that's why people are having issues. I do see merge_group.destroyed, so I'm fairly confident I'm set up correctly. I also have required checks on my branch protection, though I'm not sure that's needed.

All that to say, I'm unable to trigger my checks.

Edit: I found my issue, I needed to have an actual check for required checks to run. Now I get the webhook delivery.

[nelsonjchen]

I'm not quite sure why this is limited to organizations. That seems arbitrary. Individual users could use them.

Dependabot notices come in waves for me so tossing them all into a merge queue would be awesome.

[abernier]

I agree many popular repos (which probably need a merge-queue the most) are often created on a personal repo first(eg mrdoob/three.js), and stay like this then.

I wanted to set this up for yomotsu/camera-controls but can't due it is also a personal repo :(

Would be great if we could opt-in even for personal repos 🚀

[elasticdog]

There are a lot of communities (such as Rust), where it's common to use a merge bot for this functionality because it is such an important method of enforcing the not rocket science rule with minimal friction. One of the more popular bots Bors-NG, has now been officially deprecated and the publicly hosted instance will be going away. Being affected myself, I attempted the switch to merge queues for a personal open source project, before I realized that they were limited to organizations.

Is this just a beta limitation, or do you plan on eventually opening merge queues up for personal repos as well?

[maxdeviant]

Is there a way to view historical merges in the merge queue? It would be useful to see which PRs were merged as part of the same group, for instance.

[willsmythe]

Not currently, but we are planning some UX improvements, including a "recent activity" timeline.

[dustinblanchard]

This isn't working for us at all. The checks are staying on pending for every PR even though they completed on them prior to entering the Queue and they are added to our workflow file as:

on:
  pull_request:
    branches: [main, production]
  merge_group:
    types: [checks_requested]

[kdawgwilk]

@jiffyclub Looks like a fix was merged in soon after https://github.com/orgs/community/discussions/46757#discussioncomment-4926252

[willsmythe]

@jiffyclub - let us know if you're still seeing a problem. This issue was causing Actions workflows using merge_group to not trigger in a large number of repo.

@kdawgwilk - thanks 😄

[RCheesley]

We have this issue as well - all our PRs are being removed from the queue un-merged saying that the checks have not been reported in time. They never seem to start or complete.

[alexnb]

Our PRs seem to stay in the queue several times (each time after successful checks), every time with a merge resulting on main. Sometimes though, this loop stops and PR disappears from the queue.

[big-andy-coates]

Seeing the same issue.

Is the on.merge_group shown in the example above required to use merge queues?

I can't see any mention of it in the docs: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
Nor in the blog post linked to from the "Try merge queues" pop up I got: https://github.com/creek-service/creek-service#:~:text=with%20merge%20queue!-,Learn%20more,-about%20how%20to

[nwalters512]

Super excited to see this in public beta!

Over on PrairieLearn/PrairieLearn#7131, after adding a PR to the merge queue, removing it, then adding it again, I see a weird commit:

If I click on the commit, there's a message that says "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." I've never seen this before, so I can only assume that this is something to do with merge queues.

I'm also facing the same issue others are reporting where the checks never run.

[willsmythe]

If I click on the commit, there's a message that says "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." I've never seen this before, so I can only assume that this is something to do with merge queues.

Thanks for reporting. We're tracking an internal issue for the "This commit does not belong" message.

I have opened a second issue for the "referenced this commit" event in the timeline (these events are not supposed to appear).

I'm also facing the same issue others are reporting where the checks never run.

A fix rolled out that addresses an issue with the merge_group webhook event and Actions trigger. See #46757 (reply in thread)

If this is different than the problem you're seeing, can you start a new thread below and provide more details (what CI service are you using, if any status checks are reported, did you update your CI configuration to either trigger on merge_group or on push to the temporary branches created by the queue, etc).

[nwalters512]

Glad to hear your tracking those other two issues internally!

I'm still experiencing issues with the merge_group Actions trigger. I'll share more details in #46757 (comment) to try to keep that discussion in one place!

[willsmythe]

A fix just rolled out for the merge_group trigger. Give it another try and let us know!

[nwalters512]

@willsmythe looks like it's working now, thanks for getting that fixed!

[SanjayVas]

I'm trying to figure out the behavior w.r.t. to the "Merge method" setting. My goal is to have each PR result in a single revision to the base branch, so I currently have PRs set to squash. The base branch has a protection to enforce linear history.

What "Merge method" setting for merge queues will ensure that each PR in the queue still ends up as exactly one revision? I am concerned that e.g. "Squash and merge" here implies squashing all of the PRs in the queue into a single revision.

[willsmythe]

Good question. If you configure merge queue to use "squash and merge", each pull request will be represented by its own commit regardless of the number of pull requests the queue merges in a single operation.

[nwalters512]

Thanks for confirming! It'd be great to see this called out in the docs, as I had the same question. I'm glad to see that it does keep each individual commit.

[marcind]

+1, I assumed that the entire merge group would've been squashed together as one big commit

[willsmythe]

Cool. We'll make this clearer in the docs!

[marcind]

I'd suggest updating the wording in the settings UI. Make it clear that the selected merge strategy will be applied to each individual PR, not the group as a whole

[marcind]

I'm using a workflow to validate that every PR title matches conventions (using https://github.com/amannn/action-semantic-pull-request). The status check this action adds is configured as required for the target branch.

Having this setup causes the merge queue to stall, because the workflow never runs and the check is never set. That's because the workflow is configured to run only on pull_request triggers, which is because the action actually requires access to the PR metadata to do it's job. I can update the workflow to also run on push and merge_group (once that gets fixed), but at that point the action fails because it doesn't have a way to tell what PR it's supposed to validate.

What is the recommendation for having validation against the PR itself?

[eric-wieser]

Surely that means your queue doesn't protect against conflicting PRs breaking the build on master?

[vext01]

The opposite. We only check the tests pass when all PRs in the queue are merged into the base branch. (We don't check PRs in isolation)

This is the same as what bors-ng did before it died at the weekend.

[eric-wieser]

We only check the tests pass when all PRs in the queue are merged into the base branch

Doesn't this mean the queue is already empty, and therefore it's too late to abort the merge if the CI fails?

[vext01]

Sorry, I meant to say:

We only run the tests on the sum of the queued PRs. Not on each PR in isolation.

[vext01]

For those who want different status checks at different times (like with bors-ng) and you are using a self-hosted CI, I've written up a hack I used to achieve that here:
https://theunixzoo.co.uk/blog/2023-11-16-migrating-to-gh-merge-queues.html

[austin-schmolz]

If I try to set the "Status check timeout" to anything more than 127, it returns a 500 error. 7-bit setting?

I don't see this limit referenced in the documentation anywhere.

[willsmythe]

Thanks for reporting. We're looking into it.

[willsmythe]

A fix for this just rolled out. There was a disconnect between the DB column type (TINYINT) and the front-end validation. You can now specify a value up 360 (6 hours).

Note: I updated my reply re: 0 (no timeout) since this is not how the queue currently behaves with this value 😄 . We're evaluating.

[zhang297]

@willsmythe is there a reason why the timeout value is capped at 360? I have merge checks take slightly longer than 6 hours sometimes. Any workaround for that?

[Thunderforge]

When a PR is in a merge queue, one of the options in the … is "Jump queue". If I choose it, I get the question

Are you sure you want to force #XYZ to jump the queue? [Cancel] / [Yes, jump the queue]

I have no idea what it means to "jump the queue". Does it mean it merges immediately? Does it mean it is removed from the queue and goes back to an unmerged state? Something else?

I also checked what I thought was the documentation on merge queues and didn't see anything related to that.

[UelitonFreitas]

Will the merge queue make it available to "jump" a pull request by selected people?
We have cases where we only want certain people to be able to "jump" PRs. This way we can ensure that the merge queue is not impacted by everyone clicking in "jump" button at same time.

[jonaslindstr]

I agree with the OP that "jump the queue" might not be universally understood. At dictionary.cambridge.org it is marked with "idiom UK usually disapproving" so perhaps a different wording could be considered.

[parky128]

"Move to Front", 'Bring to Front" could would in terms of terminology - a bit like how in image editing programs where you are dealing with multiple layers and you want to bring something up the layer levels.

[changusmc]

Jumping is useful if you have a pull request that needs to get merged ASAP

How does jumping the queue help with getting a PR merged ASAP? That PR would still need to finish the merge group checks, it is no faster being in the front or back of the queue. The only thing that could affect merge-ability is if the checks are flaky.

I also want to echo restricting "jump queue" to admins.

[abchau]

Please use simple english instead of inventing a new terminology that only your team understand

[Thunderforge]

If I click "Merge when ready" on a PR, it goes into a merge queue.

But if I have a Dependabot PR and comment @dependabot merge, Dependabot gives the comment a thumbs up, but does not add the PR to the merge queue and the PR remains open.

If this is expected behavior (like it's waiting until the queue is cleared or something), that is not being communicated. I would hope that either GitHub or Dependabot would explain when it will be added. If it's a bug instead, I hope it will be fixed.

[willsmythe]

Moving comment from @jglick (https://github.com/orgs/community/discussions/46757#discussioncomment-5411001):

I noticed that there does not seem to be Dependabot integration yet: @dependabot merge is greeted with a 👍 but nothing happens and you need to add the PR to the queue yourself. (example: jenkinsci/build-token-root-plugin#123 (review)) I expected there to be a @dependabot enqueue command or something like that.

[jglick]

I have also experimented with Dependabot plus merge queue on Golang repos. It does not seem to work well. I turned off Require branches to be up to date before merging in my branch rule, since I did not want DB automatically rebasing every PR every time something else gets merged (which would make load on the CI system quadratic in the number of open PRs, unacceptable when builds are not cheap). That did not seem to be honored consistently—sometimes DB would still rebase a PR that did not seem to need it; and often it does not rebase a PR that clearly does, due to merge conflicts with the current trunk (never mind the queue!), forcing you to manually @dependabot rebase. But DB PRs for Golang update transitive dependencies, so if you have more than couple bumps open, they are likely to at best overlap in go.mod and frequently conflict; and they are almost certain to have merge conflicts in go.sum even if the bumps are truly unrelated, just because all the lines of text are close together. Also a PR with no conflicts with the current trunk but conflicts with the queue will get kicked out of the queue, and even if DB fixes the conflicts after trunk has been updated, it will not get automatically readded to the queue. The result of all this is that while you can get one DB PR merged, it is likely that all the rest will wind up with conflicts or supposedly green but removed from the queue, and so you then need to wait for the first PR to be merged and then go back and pick the next one you want to add to the queue—defeating the purpose of a merge queue, that you can just add a bunch of stuff and go to lunch.

[timothyfroehlich]

I'm hitting this as well and it's been pretty annoying. Does anyone have a workaround for this? At least such that I can manually submit dependabot PRs without disabling merge queues?

[maciej-chime]

@willsmythe can you please comment on this? Is there an ETA for when this is going to be resolved?

[ryan-dahlia]

Has anyone had any luck getting Dependabot working with the merge queue? I'm experience similar issues to those reported above: inconsistent rebasing behavior and subsequent merge conflicts.

[OneCyrus]

merge queues are a great idea until we hit limitations in the required workflow logic. Really there should be a „require all triggered workflows to succeed“ before merging. See here: https://github.com/orgs/community/discussions/13690

otherwise we still need manual approval for each PR as we need to wait for optional workflows to complete.

[willsmythe]

Thanks for raising (or re-raising) this 😄.

As mentioned in #46757 (reply in thread), we are exploring different options around required status checks. The suggestion of a simple "require any check that reports status to pass" makes sense and would be useful (regardless of whether merge queue was involved or not).

[Thunderforge]

Our projects integrate with Jetbrains TeamCity. The Pull Requests build feature (a.k.a. pre-commit builds) doesn't work with this at all. When a PR goes into the merge queue, the new builds with the latest changes are never triggered.

Unfortunately, that's going to be a dealbreaker for us for adopting merge queues. I hope that GitHub will collaborate with Jetbrains and other CI toolchain providers so that this feature can be supported.

[willsmythe]

Thanks for raising this. We'll reach out to TeamCity on this.

For context, although merge queue is part of the pull request workflow, it never actually updates the pull request (other than to mark it as merged) or generates pull_request webhook events (which may CI services listen for). Merge queue creates temporary branches that include changes from one or more queued pull requests and generates traditional push webhook events and merge_group webhook events (which are new and specific to merge queue). Each CI service will need to decide how they want to integrate and work with merge queue (and we're happy to help with this!).

[alexnb]

We also use TeamCity and our PRs seem to stay in the queue several times (each time after successful checks), every time with a merge resulting on main. Sometimes though, this loop stops and PR disappears from the queue.

[justin-brown3]

@willsmythe any idea on the naming convention for those temporary branches?

[apgosar]

Some more documentation for integration with Jenkins will be really helpful.

[vext01]

I'd also really appreciate better documentation for working with self-hosted CI systems.

[sehz]

Hi, Is there way to set commit log when squash commits similar to regular merge

[JasonGross]

There should be a way to bypass checks and add a PR to the merge queue immediately without waiting for status checks. Without this, the merge queue seems essentially useless. I have to wait 6+ hours for the status checks to finish on the PR, and then wait another 6+ hours for the merge queue to succeed?! Furthermore, it cannot be used to stack dependent PRs, because the later ones won't pass the CI off the merge queue.

[vext01]

Agreed. We have some CI jobs that build LLVM multiple times and sitting around waiting for the initial check to pass negates the point of using a merge queue.

[vext01]

Does anyone know why when using a self-hosted CI, I'm getting emails like this:

Subject: [vext01/merge-q-test] Run failed: .github/workflows/sdci.yml - zzz (2fab6b2)

[vext01/merge-q-test] .github/workflows/sdci.yml workflow run

Repository: vext01/merge-q-test
Workflow: .github/workflows/sdci.yml
Duration: 0.0 seconds
Finished: 2023-11-07 14:22:55 UTC

View results: https://github.com/vext01/merge-q-test/actions/runs/6785841064

Jobs:

I get this email even when a PR is successfully merged via the queue.

If you click the results link it says:

No jobs defined in jobs

I didn't define any jobs myself. I just followed the documentation here which suggests a config file like:

on:
  pull_request:
  merge_group:

If anyone could tell me how to silence that email, I'd be most grateful. Should I be defining a job then?

P.S.: Our CI is just monitoring "push" and "pull_request" events via an org-level event hook. It does a "fake build" that always succeeds for "pull_request" events, and a "real build" for "push" events to a merge queue branch. The fake build is needed because we don't want to do builds when the PR is raised. Currently GH appears to only allow the same set of required checks for both. Reading other threads here seems to confirm this.

P.S. again: The github docs tell you that if you are using an external CI, then it should build the branch the merege queue makes, but it neglects to tell you that github also requires a successful build just to get the PR into a merge queue. It took me ages to figure this out.

[vext01]

I managed to silence it with this hack:

on:
  pull_request:
  merge_group:

# This is required to silence emails about the workflow having no jobs.
# We simply define a dummy job that does nothing much.
jobs:
  dummy:
    runs-on: ubuntu-latest
    steps:
      - run: /usr/bin/true

It's not great. It spins up a container for no good reason...

[tj-smith47]

Within the past week, I suddenly no longer receive any merge_group.checks_requested webhook payloads. Was this removed in favor of the regular check_suite.requested payload? I'm suddenly receiving those instead, and I don't have check_suites selected. The only merge_group payloads I get are merge_group.destroyed

[tj-smith47]

I started getting them again yesterday. Maybe there's something I'm missing about when I should actually be receiving this (and why I'm getting check_suite.requested payloads while check_suite is unchecked)? It seems also like whether or not a repo has auto-merge when ready enabled, it might impact which webhooks you get. Is this the case?

I was hoping someone could give me a clear start to finish for the webhooks I should expect - and if the auto-merge setting affects this, I'd like to know the alternative webhook flow for that being enabled as well. My company is trying to incorporate these into our process, but the timing and presence of webhooks being delivered isn't at a level of consistency such that we can determine which is reliable enough to anchor onto.

Most significantly - and this may have already been mentioned: if a PR joins a queue and has a merge conflict with a previous PR, especially given that we cannot push directly to anything in the queue, there needs to be a mechanism for resolving this. I think most importantly, is that the PR joining the merge group is not informed there will be a conflict at the time they merge, and that at the time you are informed of the merge conflict, when you go back to your PR all you are told is that there are conflicts in a particular file. Not where. No suggestion for how to fix it, nor option for the typical resolution process. One or the other needs to exist. Either we need to know before entering the queue, or we need more information / enablement for fixing. I tried checking out the latest temporary branch to fix the conflict, but when I opened the file, there was no conflict.

Right now, we're trying to hold up the queue while we run tests against the cumulative changes, which to my understanding should exist in the temporary branch created for the most recently added PR in the queue. Our plan was to take that branch, deploy it for testing, and pass / fail the required check depending. However, if there is a PR in the middle of the merge group that we know will get kicked, we cannot deploy the latest branch because it will include those changes. We're not entirely sure at what point to expect that all changes that will be merged to master are present in the latest temporary branch.

[andyren0110]

It's possible that multiple PRs are merged together. In this case it'll trigger a single push event which contains all the commits being pushed to the default branch (assuming that's the branch merge queue merges into). This seems to be the only place where I could find this information. I did not find any API that allows me to query all the pull requests merged together. Maybe I missed it somewhere.

[air3ijai]

Sometimes, checks may fail because of the runners and we need a way to re-run merge queue failed checks without removing PR from the queue.

[sandstrom]

It's one year since this beta was launched!

I'm curious, do you have any plans for adding support for semi-linear merge to the merge queue?

Gitlab is working on adding support for their Merge Train functionality (same as Merge Queue).

---

Source: https://about.gitlab.com/direction/verify/merge_trains/#what-we-are-currently-working-on

cc @willsmythe

[air3ijai]

We should be able to click and jump to the check workflow which currently is executing

[jeremy-daley-kr]

What's the level of effort to allow an admin bypass to still run in the merge queue? Some PR's we want to allow bypassing CODEOWNER restrictions, but still want the merge queue workflow checks to catch race conditions.

[MichaelJJ]

One of our repos has a branch protection rule that matches all "**/*" and prevents branch pushes. We have to do this, because we want users with forked PRs to merge PRs after approvals are done, but don't want them to create branches directly in the repo (the user must have write access to merge).

It seems this breaks the merge queue functionality because the bot can't push to branches. We don't seem to be able to exempt the bot from the branch rule (it doesn't pop up in the auto-complete). Can we get the ability to exempt the bot, or just have it done automatically?

We can't exclude the special merge queue branch, because users could push to a branch with that prefix.

[OneCyrus]

Is there any up to date information regarding path-filtering support for merge queues (merge_group) in workflow definitions? It's very unfortunate not being able to use path-filtering and running so many unneeded workflows. all the time saved with merge queues is regained with way too much workflows in the queues waiting to run.

[OneCyrus]

@willsmythe this seems a real blocker for most organizations to even use merge queues. any chance you can give some feedback why this is that way and if we can expect this in the future? or if we should declare merge queues not compatible with our use cases?

[JossWhittle]

To second @OneCyrus PLEASE expedite path-filtering!

Merge groups are not useable for so many repositories because of this.

We've been patiently waiting for a very very long time for this feature now this has got to become the priority.