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)

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

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

[ybokobza]

Is there a workaround for this by using Jenkins instead of Github action?
I am blocked in the merge queue because of a status check that is not relevant to that.

[adadache]

Seems like organization rulesets doesn't respect the merge queue feature.

At least when I'm enabling "Restrict updates" with a Bypass configuration for a target branch, the ruleset will not allow for Bypass users to merge a Pull Request if a branch protection with merge queues is enabled.

EDIT:
What I'd expect, is that merge queues initiated by those on the bypass list are still allowed, initiated and eventually the PR is merged.

❌ See image below with enabled merge queue (branch protection rule):

✅ Disabled merge queue (branch protection rule):

[air3ijai]

Did a try to reproduce that, but can't find "Require merge queue" at the Organization rulesets level - do I miss something?

screenshots

Repository ruleset

Organization ruleset

Also, some reference from the documentation
Choosing which repositories to target in your organization

If a repository is targeted by a ruleset created at the organization level, only owners of the organization can edit the ruleset. However, people with admin access to the repository, or with a custom role including the "edit repository rules" permission, can create additional rulesets at the repository level. The rules in these rulesets will be aggregated with the rules defined at the organization level. The result is that creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. For more information on creating rulesets, see "About rulesets."

Do you have rulesets defined at both levels, Repository and Organization?

[adadache]

Organization rulesets doesn't have merge queues.

This is about a situation when you have Organization rulesets to "restrict updates" applied at the org level, and one of your repositories use merge queues through repository rulesets or a repo level rule as a branch protection.

[smarts]

Is this still the place to provide feedback on merge queues? If not, where should I go?
If so:
One problem I have with them is that they don't give the option to provide a multi-line commit message like normal merges and rebase merges do. Providing extra context around commits is an invaluable tool, especially when it comes to things like bug fixes. Not just unformatted text, but commit trailers too.

[smarts]

Is the configuration in the screenshot for merge queues? Or if it's not specifically for merge queues, does it also apply to merge queues?

[praseodym]

Is the configuration in the screenshot for merge queues? Or if it's not specifically for merge queues, does it also apply to merge queues?

The latter, we have only squash merges enabled with this setting and the merge queue is using that.

[praseodym]

And the merge method for the merge queue is configured as 'Squash and merge' in the repository ruleset:

[smarts]

@praseodym this ☝🏼 is exactly what I was looking for! Thank you!

[smarts]

For anyone else looking for this solution: the one gripe I have is that this does not allow you to override the commit message. The scenario I often see is this:
A software developer has a branch and they open a PR. They then get feedback, which they implement via separate commits. Then they are ready to merge. The configuration recommended in this thread does not allow the developer to override the squash commit message, which means that the resulting squash commit message includes each commit's message in the PR's branch. These are often garbage messages.

I forget which configuration allows it, but I know some configuration allows you to override the commit message upon merging. It would be nice if this feature was allowed in the squash & merge + merge queue + use PR title & commit details combo.

Disclaimer: Yes, I realize that the problem can be solved by developers changing their habits, but it would be great if the tool could facilitate an already-prevalent workflow.

So go upvote this

[iamstarkov]

API to enqueue/dequeue and view queue

is it still only available in GraphQL and not available in Rest API?

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

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

[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