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.

[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?

[mark-pictor-csec]

@willsmythe Any updates? Given how important commit messages are in any serious development effort, I'm having difficulty understanding the low priority this seems to have.

[pfac]

Funny thing: if you use the GitHub mobile app it lets you edit the commit message, but then just ignores it completely. 😑

[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)

[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.

[sandstrom]

Happy new year! 🎉

Just wanted to see if this has gotten onto the roadmap for 2025?

[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?

[ro-savage]

Looks like this isn't been actioned by Github. We are downgrading back off enterprise because Merge Queues don't work at all for us when requiring both PRs and Merge Queues to have the same required tests.

For future reference - We want our E2E test to run only on Merge Queues and our PRs to run the other tests.

We have 40+ E2E tests, and creating 40+ fakes ones that all pass on the PR is both not practically and doesn't work because we want people to optionally be able to run the E2E via tags.

Feels like Merge Queues has been created then abandoned with feedback not taken seriously.

[jduan-highnote]

Everyone at github.com is presumably working on AI related initiatives 😞

[sehz]

You can have different test for PR and Merge Queue.

[jakeatoms]

We're aware of this and are exploring options, of which is to let you control which required status checks are required for a pull request's entry into the queue vs. required for merging.

My team has started using merge queues on some of our repos and this would be huge. Right now, all the complexity has to be off loaded to our various CI build configs to determine what to run (including GH actions that do nothing but set a status check to "success"). Being able to specify a different set of required checks would really help simplify things.

I would imagine the queue rules in a ruleset would default to inherit, but could be overridden when needed.

[guillaume-mindflow]

I was considering that it might be beneficial for merge queue jobs to be treated as a cohesive workflow unit rather than just a collection of status checks to pass. This approach could ensure that workflows execute in a predictable order, particularly when they share the same backend.

With concurrency set to 1, each queued item could run sequentially, completing the entire workflow. If any status checks fail during the process, the item could be removed from the queue without interrupting the workflow’s progression.

I understand that this might increase execution time, so providing an enable/disable toggle for this feature would allow users to choose based on their need for consistency.

[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.

[crespire]

Managing this for our team, and having more options around merge queue workflows would be great.

[innomatics]

A fourth merge option: "Rebase, squash and merge" would be nice to avoid PR re-approvals on a busy mono-repo.

[Gudahtt]

The most significant limitation of this feature for my team is the lack of visibility into which checks are running for commits in the merge queue. The merge queue UI only shows required checks, but we want visibility into all checks so that we can monitor progress and view optional checks.

This is a significant departure from the PR UI, which shows all checks that are running on a given PR.

Compare the current PR UI:

With the merge queue UI:

Ideally we'd show similar information in both contexts; it's just as useful to review pending checks in the merge queue UI as it is in the PR UI.

[RalfJung]

Generally I love this feature! I've moved some repos to new, tiny orgs just to be able to use merge queues. ;)

I have one minor issue: the automatic commit created by GH has a description like this:

Merge pull request #4020 from RalfJung/thread-sope

The problem with this is that in larger developments, it can be part of the usual process to move commits between repositories. For instance, in Rust, this directory of the main Rust repo also exists as its own repo. This isn't a submodule, as those are quite painful, it is using a different sync technique. The details don't matter. What matters is that we are using a merge queue in the subrepo, so commits like the above are being created there, and then the sync moves that commit into the main Rust repo.

The reason this is a problem is that the pull request #4020 reference will be wrong now: it will refer to PR 4020 in the main Rust repo, rather than in the subrepo.

So, it would be great if the bot that creates these commits could reference PRs in a way that still makes sense when the commit is moved to a different repository.

[rjhuijsman]

I'm evaluating your Merge Queue feature against "dedicated" offerings like mergequeue.com - and I'm hitting a bit of a show-stopper for us.

Our repo is "bursty" - sometimes we have several PRs in the queue, but oftentimes it's just the one, normally already rebased against main. In those single-PR cases I must still wait for my tests to pass twice: once before the PR is enqueued, and again when the PR is put at the head of the (single-item) Merge Queue. Our tests take a long time, and assuming that my PR ran rebased on the latest main, we're just re-running all the same checks on all the same code - there's no way it should give any different answer. We're just burning time, CPUs, and money for nothing.

With our usage pattern, it's (much) cheaper for me to pay for mergequeue.com than to use your offering - because mergequeue.com doesn't do that redundant re-check.

For Merge Queue to work productively and cost-effectively for us, I'd want the head of the queue to merge immediately if it had already passed all required checks while being fully up-to-date with main. In other words: if the re-check is redundant, just use the PR's checks instead.

Separately, not a show-stopper, but also important to us: with mergequeue.com we use two different labels (mergequeue-ready and mergequeue-rebase) to decide on a PR-by-PR basis whether to squash-and-merge or rebase-and-merge - it's a convenience to not have to manually squash all commits in a PR, but sometimes you actually want all the commits to stay separate. We'd like to do PR-by-PR selection on GitHub also.

On the positive side: I found your Merge Queue feature to be easier to set up than mergequeue.com. 🎉

[gustavovalverde]

You might want to try Mergify

[Pooh-Cherry]

https://docs.github.com/en/graphql/reference/mutations#enablepullrequestautomerge

plz check this.

[Belgarus]

ok

[Pwuts]

"New Merge Experience (beta)" breaks when trying to remove a queued PR from the queue. Clicking that button on the PR gives a "Not Found" error.

[Belgarus]

It sounds like you've encountered a bug in the "New Merge Experience (beta)" when trying to remove a queued PR. Here are a few possible explanations and troubleshooting steps:

Possible Causes:

1. Permission Issues – Ensure you have the correct permissions to manage the queue and remove PRs.
2. UI or API Bug – The beta version may have an issue where the removal action is not properly processed.
3. PR Already Merged or Deleted – If the PR was merged or deleted before you attempted to remove it, the system might not find it.
4. Cache/Session Issue – A stale session or cached data could be causing the error.

Suggested Fixes:

• Try refreshing the page and attempting the removal again.
• Check if the PR still exists in the repository. If it was merged or closed, that might explain the "Not Found" error.
• Clear browser cache or try using an incognito window.
• Use GitHub CLI or API to manually remove the PR from the queue if possible.
• Report the issue to GitHub Support if it persists: GitHub Support.

Since this is a beta feature, bugs are expected. You may also want to check GitHub’s [Merge Queue Documentation](https://docs.github.com/) for any known issues or updates.

[topherfangio]

Finding it REALLY difficult to get to the merge queue from anywhere in the GitHub app.

It would be awesome if there was a button somewhere in the interface that said "Merge Queue" that you could click on. Ideally, this would be under the Code tab, or Actions tab.

I could have sworn this was available somewhere, but now I can't find it.

If it does exist, it feels very hidden and needs to be brought up in the hierarchy.

Thanks! 😄

[praseodym]

It's available in every pull request through the "merge queue" at the bottom and from the Code tab -> Branches -> Merge queue column.

[ujain6]

Problem
We have multiple status checks enabled for the merge queue on our master branch. One of them is a very short mergeability check whereas the other one is a full Bazel build & test pipeline.

The longer status check spawns multiple matrix jobs.

Whenever the mergeability check fails, GitHub deletes the temporary merge ref created.

Since the matrix jobs spawned by the second longer check are configured to check out the same merge ref that the first check failed on, when they finally get scheduled to run, they fail on actions/checkout.

The error seen is of the form couldn't find remote ref refs/heads/gh-readonly-queue/master/pr-xx-<SHA>

We believe GitHub does not wait for all required status checks to conclude before deleting the temporary merge ref created. This results in a race condition between multiple status checks triggered for the same merge group

[Belgarus]

It appears that GitHub is deleting the temporary merge ref as soon as the first status check (the mergeability check) fails, without waiting for all required checks to complete. Since your Bazel build and test pipeline runs multiple matrix jobs that rely on the same merge ref, they fail when trying to check out a ref that no longer exists.

Suggested Solutions

1. Ensure Required Status Checks Are Fully Evaluated Before Deletion
GitHub should ideally wait for all required status checks to conclude before deleting the temporary merge ref. If this behavior is unintended, it may be worth reporting it as a bug to GitHub support.

2. Use actions/checkout@v4 with fetch-depth: 0 as a Workaround
Although this won’t prevent the deletion, you might mitigate failures by modifying your checkout step:

- uses: actions/checkout@v4 with: fetch-depth: 0

This ensures that even if the ref is deleted, your job might still proceed by checking out the latest commit manually. However, this may not work in all cases.

3. Modify Your Merge Queue Configuration
If possible, configure GitHub’s merge queue to avoid running the longer pipeline when the quick mergeability check has already failed. You could:

Run the mergeability check first and only trigger the full Bazel pipeline if it passes.
Ensure that matrix jobs do not depend on the deleted merge ref but instead use an alternative branch reference or a saved commit SHA.

4. Raise an Issue with GitHub
If this is an unexpected behavior, you should report it directly to GitHub’s engineering team via GitHub Support or discuss it in the merge queue feedback forum.

Let me know if you need further clarification or an alternative workaround! 🚀

[dkfellows]

If the checkout of the repository is small enough, you could structure the Bazel workflow to have a fast job that checks out the commit to test against and saves it as a short-lived artefact. Then, the matrix jobs (explicitly set to be downstream of that) can get the code to work with from that artefact instead of checking out the potentially-deleted commit.

You'll still have a problem if the first job runs after the basic check cancels everything, but it should minimise things. (Using a standard Ubuntu runner seems to minimise the problems; they run fastest and most promptly in my experience.)

[sunshine-syz]

Is there a way to only run tests "combined" PRs. For example, I have PR1, PR2, PR3. Then the merge_queue will create 3 CI tests
PR1, PR1+PR2, PR1+PR2+PR3. But our CI testing is "expensive". Is there a way to only run test for PR1+PR2+PR3 like batched PR?

[Belgarus]

Yes, GitHub's Merge Queue currently does not support skipping individual PR tests and only running tests on the fully combined batch (e.g., PR1+PR2+PR3). However, you can achieve a similar effect using batched merging by adjusting your merge queue settings:

1. Use "Batch Mode" in Merge Queue
GitHub’s merge queue allows batching multiple PRs together, running CI once on the combined set before merging.
This is configured by setting batch_size in the merge queue settings.
If your repository is using GitHub Actions, you can define conditions to run CI only on batched PRs.

2. Customize Your CI to Detect Merged PRs
Modify your CI workflow to detect whether a PR is part of a batch and conditionally skip tests for individual PRs.
You can check GITHUB_REF or GITHUB_EVENT_NAME in GitHub Actions and only trigger tests for the last combined PR.

3. Use a Custom GitHub Action or Workflow
You can create a workflow that triggers CI only when a PR reaches a predefined batch threshold.
Example:
jobs: run-tests: if: github.event.pull_request.merged == true && github.event.pull_request.base.ref == 'merge-queue' steps: - run: ./run_tests.sh

4. Alternative: Implement a Custom CI Trigger
Some users use external CI/CD tools (Jenkins, CircleCI, etc.) with merge queues that allow defining when tests run.
If using GitHub Actions, a workaround is setting an environment variable or label to determine when CI should run.

While GitHub doesn’t natively support skipping individual PR CI runs within a merge queue, using batch mode or customizing CI workflows can help reduce redundant tests and optimize resources.

[Apakottur]

Hi, we have the following action:

name: Backend | Push

on:
  push:
    branches:
      - master
    paths:
      - 'backend/**'

jobs:
    ...

If we merge/add multiple PRs to the merge queue, then the action only runs on the last PR in the queue.
This means that if we merge two PRs, PR_1 which modifies files in backend and PR_2 which does not, then the action will run for PR_1+PR_2, with github.sha being equal to the SHA of PR_2.

We use the SHA of the PR to tag artifacts generated by this action, and other steps in our CI fail because they cannot find artifacts generated by this action for PR_1 (as the action is only run for PR_2).

Is there a way to run this action on PR_1 even though PR_2 is further in the merge queue? Or is there another way for me to guarantee this action runs for any PR in the merge queue (or at least the last one matching the path filters)?

[Belgarus]

To address the issue where your GitHub Action only runs for the last PR in a merge queue, you need to adjust both the event trigger and the SHA used for artifact tagging. Here's the solution:

1. Use the merge_group Event

Switch from the push event to the merge_group event. This ensures the workflow runs for each PR in the merge queue that matches your path filters, even if subsequent PRs don't modify those paths.

on:
  merge_group:
    branches:
      - master
    paths:
      - 'backend/**'

2. Use the Correct SHA for Artifacts

In the merge_group context, use github.event.merge_group.head_sha to get the individual PR's SHA instead of the merge commit SHA:

jobs:
  your_job:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.merge_group.head_sha }}

      # Your build/test steps here

      - name: Tag artifact with PR SHA
        run: |
          echo "PR SHA: ${{ github.event.merge_group.head_sha }}"
          # Use this SHA to tag your artifacts

Why This Works

• merge_group Event: This triggers the workflow for each PR in the merge queue that modifies backend/**, ensuring individual runs per qualifying PR.
• PR-Specific SHA: github.event.merge_group.head_sha refers to the HEAD commit of the PR branch, allowing correct artifact tagging for each PR.

Additional Notes

• Ensure your repository has merge queue functionality enabled (available in public beta).
• If you need to run actions even when a PR doesn't modify backend/**, consider removing the paths filter or using separate workflows.

This approach ensures each PR in the queue that affects backend/** triggers the action with its own SHA, resolving the missing artifact issue.

[nickruddeni]

We attempted to use a merge queue in conjunction with Bitrise CI and quickly ran into the following issue:

1. We want pull request status checks to pass (via Bitrise) before adding to the queue. This necessitates a required status check of a pull request triggered CI run
2. We need the push triggered runs via the merge queue temporary branches to be required status checks

1 is not fulfilled on the temporary branches and 2 is not fulfilled on the pull request. Enabling one or the other means you either can't add to the merge queue, or you can add to, but the merge queue status checks never get reported and thus no merge happens.

We need to be able to configure status checks to enter the queue differently from the checks required for the queue to perform a merge. Without that, it's not usable.

[ghostinhershell]

Hey all! 👋🏾

We are very happy to announce that the Pull Request Merge Queue is no longer in Beta and has reached General Availability (GA). You can learn more in the Changelog post here: Pull request merge queue is now generally available!.

We appreciate all the feedback and contributions from everyone who participated in this discussion! So much so that we made sure to also include a special thank you to the community members who participated here in the Changelog post as well.

As the feature is now live, we will be closing out this discussion. If you have any additional questions or need further assistance, please create a new post in the Pull Requests category.

Again, thank you all for the outpouring of support and contributions! You're truly what makes GitHub great! ✨ 🚀

[air3ijai]

And after 2 years of feedback most confusing part and most requested feature/fix "Require different status checks for a PR's entry into the queue vs. for merging by the queue" is still in place?

[sandstrom]

@ghostinhershell Happy to hear it's GA! 🎉

Can you provide some thoughts on supporting 'semi-linear merge' as a strategy for the merge queue?

https://github.com/orgs/community/discussions/14863

Semi-linear merge is supported in Gitlab and Azure Devops.

---

There is also this discussion thread about supporting semi-linear merge more broadly in Github.

[theoparis]

I just tried using the merge queue feature with multiple branch protections enabled via a ruleset, however when the merge queue bot tries to merge my PR it complains with:

github-merge-queue bot removed this pull request from the merge queue due to Branch Protection failures 7 minutes ago
You're not authorized to push to this branch. Visit "About protected branches" for more information.

Any ideas?