Run workflow _only_ on merge_group

[Snaipe]

Select Topic Area

Question

Body

I have a job that performs a deployment. That deployment mutates infrastructure, so it is critical that:

1. it runs on direct pushes, manual dispatches, and periodically
2. it does not run on pull requests, as we do not want WIP, unreviewed, untested changes to apply infrastructure changes.
3. when a PR is merge-ready, that the infrastructure changes get applied, and...
   a. if that succeeds, the PR merges.
   b. if it doesn't, the changes get reverted, and the PR stays open.

It seemed to me that the right way to fulfill point 3 was to force the use of a merge queue. The idea is that the job would run when the PR enters a merge group, and if it succeeds, it would get merged, while if it did not succeed, it would get dequeued from the merge queue.

However, this just doesn't seem to be working.

Attempt one: just using the obvious on: merge_group:

name: Apply Infrastructure Changes

# Make sure we're only running these infra-mutating jobs one at a time
concurrency:
  group: production

on:
  # Apply infrastructure changes on push
  push:
    branches:
    - main

  # Apply infrastructure changes while in the merge queue.
  #
  # If this fails, the change should get kicked from the merge queue, and
  # the changes should be reverted.
  merge_group:
    branches:
    - main

  # Repo admins should be able to trigger this
  workflow_dispatch:

  # Apply/repair infrastructure changes every day.
  #
  # This is particularly important, as some resources (like certificates)
  # expire over time; running this every day avoids keeping expired certificates
  # around, and renews them automatically.
  schedule:
  - cron: '0 0 * * *'

jobs:
  apply_changes:
    environment: production
    
    steps:
    - uses: actions/checkout@v3
    - ... more steps

This doesn't work. When pressing "Merge when Ready", the PR gets added to the merge queue, waits a bit, then promptly merges the result without running the job.

Attempt 2: adding pull_request on top of that

All examples seem to specify both on: pull_request and on: merge_group; OK, but due to point 2 I don't want to apply the changes during the pull request checks, so I'll just make sure it just targets the enqueued type.

@@ -14,6 +14,8 @@ on:
   #
   # If this fails, the change should get kicked from the merge queue, and
   # the changes should be reverted.
+  pull_request:
+    types: [enqueued]
   merge_group:
     branches:
     - main

That sure didn't work. Just like attempt 1, the PR gets added to the merge queue, no new job runs, and it gets merged almost immediately.

Attempt 3: maybe pull_request needs to be there for qualification?

Okay, maybe the pull_request job needs to physically exist and run on the pull request in order for it to rerun on the merge_group. Maybe I can just skip the job if it's not the enqueued action? That probably works better since I'm not seeing enqueued being part of the activity type list for pull_request, but I do see it for the webhook payload value under action, which should be accessible under the github.event context.

@@ -14,6 +14,9 @@ on:
   #
   # If this fails, the change should get kicked from the merge queue, and
   # the changes should be reverted.
+  pull_request:
+    branches:
+    - main
   merge_group:
     branches:
     - main
@@ -33,6 +36,9 @@ jobs:
   apply_changes:
     environment: production
     
+    # Prevent the job from triggering if this pull request hasn't been enqueued
+    if: github.event_name != 'pull_request' || github.event.action == 'enqueued'
+
     steps:
     - uses: actions/checkout@v3
     - ... more steps

Nope. Still not working with the same symptoms as attempts 1 and 2, except that now job appears skipped on the pull request but doesn't trigger when the pull request gets enqueued.

#26724 vaguely mentions that merge queues are supposed to be solving this use-case but it clearly doesn't as far as I can tell. Am I missing something here?

[krzkafor]

Having exactly the same problem. We want to have end-to-end testing only triggered when a PR is ready to be merged into the main branch and not before. After all PR checks succeeded and resolved all the PR comments when I click green add to merge queue button, there are no additional checks running and I just get an email notification that it was merged.

[krzkafor]

@Snaipe I created a ticket regarding this issue from my enterprise account and they responded with the below answer which got my workflow working as expected, enjoy :)

The merge_queue will only run on required checks and it needs the pull_request trigger as well.
If you add a pull_request trigger and making the job a required check under the repository's
Settings > Branches > Branch protection rules worked.

A workaround that others have used is to have the job getting skipped unless it is an actual enqueued event:

on:
 pull_request:
 merge_group:

jobs:
    if: github.event_name != 'pull_request' || github.event.action == 'enqueued'

While we don't currently have the functionality implemented to use merge_group as a "normal" Actions workflow trigger, I've gone ahead and added your organization's voice to the internal Issue tracking the feature request that we created original for some other customers and the folks in the GitHub Community and looped in your account representative. At this time we can't say when or if it will be released but we'd recommend that you keep an eye on the GitHub changelog where updates are announced.

[ryanjlind-unity]

I am having trouble with this.

I find that if I add them to the required checks under "Settings > Branches > Branch protection rules" then I can't even add it to the merge queue. It will just sit there on "45 expected checks" and say that those checks must pass before it can merge. But I want those checks to run on the merge queue! I don't want them to run on pull_request. If I use the above method they won't get "skipped" but just hang on "Expected — Waiting for status to be reported" forever.

I don't understand how we can have jobs that don't run on pull_request but run on merge_group. And if we can't have this then I don't understand the point of merge queues.

[yarindeohcld]

+1 on what @ryanjlind-unity raised

[MChen7209]

Only way I could still use both PR and Merge Queues separately was to have it so both had a job at the end with exactly the same name which would check to see if all the other jobs passed. I would then add it as a required status for merging into the protected branch. Without a required status check the merge queue immediately merges.

pr.yml

name: PR Tests

on:
  pull_request:

jobs:
...
  check-ci-passed:
    if: ${{ always() }}
    name: CI Passed
    needs:
       - a
       - b
       - c
       - d
    runs-on: ubuntu-latest
    steps:
      - name: Fail if any failed
        shell: bash
        run: |
          if [[ "${{ contains(needs.*.result, 'failure') }}" == 'true' ]]; then
            exit 1;
          fi

merge_queue.yml

name: Build and Release

on:
  merge_group:

jobs:
....
 check-ci-passed:
    if: ${{ always() }}
    name: CI Passed
    needs:
       - e
       - f
       - g
       - h
    runs-on: ubuntu-latest
    steps:
      - name: Fail if any failed
       ...

[paulo9mv]

I don't understand how we can have jobs that don't run on pull_request but run on merge_group. And if we can't have this then I don't understand the point of merge queues.

You should do similar as @MChen7209 mentioned. Assuming that job-1 is required, the way I do is like this:

on:
  merge_group:

jobs:
 job-1:
    name: Job 1
    runs-on: ubuntu-latest
    steps:
      - run: echo "Do something here"

on:
  pull_request:
    types:
       - synchronize

jobs:
 job-1:
    if: false
    name: Job 1
    runs-on: ubuntu-latest
    steps:
      - run: echo "Job 1"

Basically if you don't want to run a job on your PRs (or merge queue), just repeat that job but with if: false.

[avalatea]

I have nothing to add, just that this would be a really valuable feature for my team. The use case:

• My org builds containers via org-wide secret variables supplied by GitHub.
• We want to run tests against code against these built containers and make sure they pass before they merge in.
• My team uses a forking strategy, which means that secret variables are not passed when we need to run tests using the pull_request trigger.
• Therefore, we cannot build the container needed to run tests, since our forks cannot access the org-wide secrets.
• The merge queue bypasses this restriction, because it creates a temporary upstream branch based on the forked PR.
• This temporary branch does have access to our org-wide secrets because the branch belongs to upstream.
• Therefore, we can build the containers and run tests without merging code into our production branch.

[emileten]

This would be a very valuable feature for us as well ; the use case is like that of the original author. The job performs a deployment, and we would like this job to run only when someone submits a PR for merge to main and we would like the PR to be cancelled if the job fails. merge_queue seemed to be the right answer, and I attempted something identical to option 1 outlined above, without success.

Although I am going to try some of the workarounds mentioned, I still think it would be great to have a clean solution !

[zaw-win]

One way that works for me is:

1. Allow auto-merge flag turn on in Settings / General page.
2. Setting your Github Actions trigger on types 'auto_merge_enabled' like this:

  pull_request:
    types:
      - auto_merge_enabled
    branches:
      - main

3. Turning on Require status check to pass before merging flag in Settings / branch page and adding the list of Github Actions jobs there, including the jobs that will only be triggered by the action above in step 2.
4. Go to your PR and click on 'merge when ready' when you are ready to merge. That will set auto_merge_enabled and trigger the jobs before finally merging to main.

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