GitHub's new "Merge Queue"

[vedantmgoyal9]

A new feature named "Merge Queue" has been released by GitHub. I would suggest Microsoft organization to atleast join the waiting list. It could be helpful for repositories like winget-pkgs.

More information here: https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/

[vedantmgoyal9]

cc @denelon

[denelon]

I took a look, and I've started the process to see about getting access. I'm not sure we have the specific problem identified (yet), but it would be nice to know what kind of scenarios this might help with.

[vedantmgoyal9]

After reading the article two more times and my comments again, I finally realised that I'm not able to explain what I have observed and can be fixed by this feature. @jedieaston is correct on his part.

[vedantmgoyal9]

I think 🤔 then we will no longer have to depend on @msftbot for merging PRs, it will just have to add the PR to the queue and GitHub will take care of merging PRs.

[denelon]

We use @msftbot to help add appropriate labels and check for which user has performed an action. We're refactoring this a bit to leverage a GitHub team so we can centrally manage this. We still see value in using @msftbot handling the merge action. It has some limitations that have lead to a bit of the complexity we have today, but we don't have a better tool at this point, and building one ourselves doesn't seem to be all that valuable yet. Maybe this will change over time, but for now, it's the best solution we have available.

[jedieaston]

depend on @msftbot for merging PRs

If there's API access for this feature (which may or may not exist in private beta, I don't know if it'll use the same merge endpoint or not), msftbot could be patched to be able to use it so the rest of the flow doesn't get broken. But that's not this team.

Tangentially related explanation: #13643 (comment)

[vedantmgoyal9]

Actually I was very eager to enroll myself but it needs me to be an admin of an organisation which I am not. Even if I create a new organisation, it needs the repo to have sufficient number of PRs which I cannot create in a short time. If @denelon could pass this issue internally, and get the organisation enrolled, we could test te feature and see if it can be useful here. However by only seeing the preview embedded in the post, I think that after when this is released, we don't have to "reapprove" PRs so that it can be merged.

[jedieaston]

we don't have to "reapprove" PRs so that it can be merged.

I've never had the problem described in the article, rather our problem (as I understand it) is that msftbot tries to internally calculate the merge before it "clicks the button". Most PRs stay green, but msftbot doesn't come to the same conclusion before the 1 minute timeout.

I don't know why msftbot has to separately calculate the merge (surely it can just ask GitHub's API "is this good to go?"), but if that's a hard requirement, then this won't solve our problem.

[vedantmgoyal9]

Most PRs stay green, but msftbot doesn't come to the same conclusion before the 1 minute timeout.

That's what I meant when I said "we don't have to "reapprove" PRs so that it can be merged."

[jedieaston]

But the reason we have to reapprove is to trigger msftbot to start its merging process, which is not the problem described in the article.

[vedantmgoyal9]

I can open a support ticket and ask for beta access (they've been very friendly in giving me acess for copilot and codespaces). I would verify it myself since I'm not clear with the information provided in the article.

[Trenly]

I agree with @jedieaston and don't think it resolves any issues with the current PR situation