Branch Protection Rules on Merge Queues

[mkjost0]

Select Topic Area

Question

Body

Hi! I'm currently trying to set up a repository to use merge queues, and was trying to figure out how to set the proper branch protection rules to have our tests run on the right events. We want to be able to have one set of tests run when a pull request is created, then a different set of tests to run when these pull requests enter the merge queue, and be required to pass before they can be merged. However, when we set status checks in the branch protection rules, we find that they only apply to our pull request, so any subsequent event that we have run on a merge_group event doesn't need to pass, or even finish, before the pull request can successfully leave the merge queue. On the other hand, if we include the tests that run on the merge queue as one of the status checks, our pull request never enters the merge queue, as it is expecting these checks to pass before they can enter. How can we configure our rules so that we can require tests that only need to be run within the merge queue to pass before they merge, while not duplicating these tests to run on pull request events as well? Thanks!

[queenofcorgis]

Hey there... can you share the events / rules you've created - that may give folks a better shot of being able to help?

[mujeeb00]

Setting up a repository with merge queues and proper branch protection rules can be a bit tricky, but I can help you configure it to achieve the desired behavior. To have distinct sets of tests running for pull requests and merge queue events without duplication, we'll need to use a combination of GitHub Actions and branch protection settings. Here's a step-by-step guide:

GitHub Actions for Tests:

First, create two separate GitHub Actions workflows, one for tests on pull requests and another for tests on merge queue events.

For the pull request tests, you can use the default pull_request event trigger in the workflow YAML file. These tests will run whenever a pull request is created or updated.

For the merge queue tests, use a custom event trigger. Since GitHub Actions doesn't have a native merge_queue event, you can use workflow_dispatch as a custom trigger event. When you trigger the workflow manually for the merge queue, you can pass additional inputs to distinguish it from regular pull request tests.

Branch Protection Rules:

Go to your repository settings, then select "Branches" and "Add rule" for the main branch or the branches where merge queues are enabled.

Add a required status check for your pull request tests workflow. This ensures that all pull requests have to pass these tests before they can be merged into the protected branch.

To prevent the pull request tests from running when entering the merge queue, set the branch protection rule to allow "Require branches to be up to date before merging." This ensures that only the merge queue tests need to pass before the merge happens.

Manually Triggering Merge Queue Tests:

Whenever you're ready to send a pull request into the merge queue, manually trigger the merge queue workflow using the "Run workflow" button in the GitHub Actions tab. When triggering it this way, you can provide the necessary inputs to differentiate it from the regular pull request workflow.
By following this setup, your pull requests will go through separate sets of tests, and they will only enter the merge queue when the merge queue tests pass. The pull request tests won't block the merge queue process, and you won't have to duplicate any tests.

Remember to adjust the workflow YAML files and branch protection rules according to your specific branch and workflow naming conventions.

Hope this helps! If you have any further questions or need additional assistance, feel free to ask. Happy coding!

[AlexMoutonNoble]

Hi Mujeeb
Are you suggesting a manual step for running merge queue tests for every PR submitted?
This doesnt seem feasible as an automated process in an organization.
Is there another way?

Thanks
Alex Mouton

[mujeeb00]

Hi Alex,

You're right, manual steps for merge queue tests aren't ideal. To automate, consider these steps:

Use GitHub webhooks to trigger merge queue tests after successful PR tests.
Adjust workflows to run merge queue tests based on conditions.
Explore GitHub Apps for more advanced automation.
Create a custom event using workflow_dispatch for merge queue differentiation.
Feel free to ask more.

Have a good day,
Mujeeb ur rehman

[kojoru]

Hi,

I've struggled with the same issue and finally figured it out. I've explained my approach in the article I wrote about my findings.

The gist of it is that you need to create two workflows - one for merge_group event, and another one for pull_request event, but both should have the same job name. Then you can use that job name in the branch protection rules, and it will happily accept both workflows for merging.

[cjthom03]

Thank you @kojoru - this seems to be working for us so far. It is... unfortunate that this required, to say the least. Maintain the duplicate files is going to be super fun! We are going to try it out for a while and see how it goes. Have you run into any issues with this approach so far?

[kojoru]

We haven't been running it on a large scale yet - I've only run this in proofs of concept.

Note it doesn't have to be duplicate files - another thing that you can do if your pre-queue and post-queue flows are similar is to cover some steps with conditionals and set both events in the same workflow.

[AlexMoutonNoble]

Thanks Konstatin We are trying your pattern now A

…

On Thu, Aug 17, 2023 at 6:14 PM Konstantin Yakushev < ***@***.***> wrote: Hi, I've struggled with the same issue and finally figured it out. I've explained my approach in the article I wrote about my findings ***@***.***/how-to-set-up-merge-queues-in-github-actions-59381e5f435a> . The gist of it is that you need to create two workflows - one for merge_group event, and another one for pull_request event, but both should have the same job name. Then you can use that job name in the branch protection rules, and it will happily accept both workflows for merging. — Reply to this email directly, view it on GitHub <#61326 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APRNFBXZAPDKZSOEUAIW6YDXV26WXANCNFSM6AAAAAA2RA4IOE> . You are receiving this because you commented.Message ID: ***@***.***>

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[sh977218]

@mkjost0 Hey, did you get solution for your problem? I am having exact same doubts as well. After 3+ years, I wonder how GitHub has been changed to this problem, or not?