Merge queue specific checks

[eduprozo]

Select Topic Area

Question

Body

I'd like to have required status checks as branch protections ONLY for merge queue PRs. At the moment, I can only enable them for what seems to include all PRs, merge queue ones included. This leads to having to run things twice, when users open a PR and when the queue opens a gh-readonly PR as well.

Things I've tried:

• Use rulesets to only run checks on merge queue PRs: I get Push Blocked error
• PR Path filtering: doesn't work

Any ideas on how to get this done? Or is it not supported (discouraged even?) at all

[ghost]

This is a known issue (almost 1 year already) and this is because status and merge checks jobs coupled. And currently we have just some workarounds for that.

Run workflows on both events

1. Run PR and MQ workflows on both events and add their jobs in the list Require status checks to pass before merging under branch rules

   on:
    pull_request:
    merge_group:

2. Use conditional job execution in PR and MQ workflows

   # PR
   if: github.event_name != 'merge_group'
   # MQ
   if: github.event_name != 'pull_request'

3. In case of matrix, we also can use an additional job, which will check matrix status and use just it under branch rules

   jobs:
     build:
       strategy:
         matrix:
           node: [16, 18, 20]
         ....
   
     status-check:
       if: always()
       needs: [build]
       runs-on: ubuntu-latest
       steps:
         - if: ${{ contains(needs.*.result, 'failure') || contains(needs.*.result, 'cancelled')  || contains(needs.*.result, 'skipped') }}
           run: exit 1

In that way

• Both jobs will be started on PR and MQ
• Only required steps will be executed and all required jobs will report their status to pass checks

Use same job name for PR and MQ

1. Create a job with the same name in PR and MQ workflows - status-check
pr.yaml

   name: PR
   
   on:
     pull_request:
   
   jobs:
     status-check:
       runs-on: ubuntu-latest
       steps:
         - name: PR check
           run: sleep 10

   mq.yaml

   name: MQ
   
   on:
     merge_group:
   
   jobs:
     status-check:
       runs-on: ubuntu-latest
       steps:
         - name: Merge queue check
           run: sleep 120

2. Add just status-check job under branch rules

3. In case of matrix we can use an additional job as well

In that way

• Only required workflow will be started on each event
• On PR and MQ steps check will pass because in both cases required job (by name) will be executed

[pchugh17]

@air3ijai air3ijai
We are using Custom CI(Jenkins) and not Github Actions. Is it possible to achieve some level of filtration using Default Webhooks delivery service by Github?

[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! 💬

[lara-newsom]

I implemented different steps with the same name for each event on a test repo, but it is not an ideal solution. It would be a nice feature to be able to set a different set of required checks that run only on the merge_group event to avoid running expensive parts of the pipeline twice.

It would also be nice to have the merge group checks show up on the PR in the 'checks' panel by default.

This is the result of a failed check in the merge group event when I have two steps with the same name that run different commands.

[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! 💬

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

[jswager-cisco]

We use Jenkins and merge queues. Encountered the same problem, but have a workaround sort of similar to the GitHub actions. We use Pipeline Script style jobs; they can detect - based on the branch name - when they're running against a PR or against a Merge Queue branch. When they run against the Merge Queue branch, we don't execute all the validation tests, so some of the PR checks aren't present. But because we can detect when the build is running against a MQ branch, we fake the PR checks, using something like this:
pullRequest.createStatus(status: 'success', context: contextName, description: "Fake Check", targetUrl: "${env.JOB_URL}")
where contextName is the name of the check. Mostly copied from this example of the Jenkins Pipeline-GitHub plugin. https://plugins.jenkins.io/pipeline-github/#plugin-content-creating-a-commit-status-against-the-head-of-the-pull-request You could probably also do this all with a curl call an API token.

[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! 💬

[horatiu-udrea]

It would be nice to have separate settings in rulesets for required checks on pull request and merge queue.

[michaelcaterisano]

+1, it would be great to be able to specify required checks specifically for the merge_group

[gilvan-fernandes]

+1. Same issue with CircleCI.

[mdarvanaghi]

We also need different required status checks for merge queues.

[the-kenneth]

+1 this would allow a lot simpler setup and common use cases such as running a specific set of expensive tests on merge queue only