Trigger workflow only on pull request MERGE

[MatteoGioioso]

I saw many posts about people asking if there is a way to trigger the workflow only on MERGE, which to me seems the most useful. However I did not see any answer, so I would like to find a solution.

At the moment I am stuck with:

on:
  pull_request:
    types: [closed]

Which is not ideal, as it would trigger the entire process even if I dismiss or close the PR without merging and I cannot see any reason on why this should happen.

I saw also: 

github.event.pull_request.merged == true

but as my understanding this would run only for a particular action not on the entire workflow.

So my question is: how can I trigger a workflow only on pull_request merge?

Thanks

[ludowkm]

same question

[jenschelkopf]

There’s no way to specify that a workflow should be triggered when a pull request is merged. However, because a merged pull request always results in a push, you can use the push event to accomplish your goal.

For example, let’s say that you want to run a workflow whenever a pull request is merged to your master branch. You can do something like this:

on:
  push:
    branches:
      - master

This workflow will run when a PR is merged or when a commit is made directly to the master branch.

You can list multiple branches if you’d like:

on:
  push:
    branches:
      - master
      - develop

Or use a more sophisticated filter pattern.

[okainov]

Even though the first sentence is clearly wrong (there is a way to see whether PR was merged), this should be an accepted answer as it provides the most standard and straightforward solution.

[augustoapg]

@okainov how could we check if PR was merged?

[okainov]

Because the only way how commit can end up in master is via PR merge, as simple as that. Otherwise it means you can manually push anything which breaks the whole idea of having CI and validation. One MUST protect master branch, this should go without saying.

[okainov]

@augustoapg the other answers below are exactly about to check PR states :)

[acjay]

@okainov That's an opinion on how best to use GitHub, and even though I agree that it's good practice, it's not a technical requirement of Git or GitHub. By default, you can also hard reset your master branch locally and force push it to GitHub. I've done this before (whether or not it was a good idea). Therefore there's a technical difference between setting up a trigger on pushing to master vs merging a PR.

[BrightRan]

For the event on.pull_request.closed , it is designed that whenever the PR is closed the workflow will be triggered. And currently, there is not a specialized event type for PR merged, such as on.pull_request.merged.

You mentioned the value of the property github.event.pull_request.merged is true when you close the PR without merged. I tried both manual and the GitHub REST API Update a pull request to close the PR without merged, the value of the property merged always is false on my side.

I also tried the API Get a single pull request, from the response body, the value of property “ merged ” is consistent with that in github context.

What methods did you use to dismiss or close the PR? Maybe you also can try using the API Get a single pull request to check whether the value of property “ merged ” is consistent with that in github context.

If the value is back to correct, as a workaround, you can use this property in the if conditionals to run all the jobs in the workflow only when the PR is closed with merged.

For example:

jobs:
  build:
    if: github.event.pull_request.merged == 'true'
    . . .

This will still trigger the workflow but can skip the jobs in the workflow.

[ruiheesi]

I encountered his problem too when using
on:
pull_request:
types:
- closed
branches:
- main
With
if: ${{ github.event.pull_request.merged }}
The workflow was trigged without merge...

[dhanakane-vc]

if: ${{ github.event.pull_request.merged }}
You're evaluating a string with this statement, not if the string value matches something, so this will always evaluate to true. Probably why your workflow always triggers.

[MatteoGioioso]

Even though I still would prefer a merge option, I think this makes sense. Thanks

[AnthonyWC]

I use this which triggers on merge:

- name: pull request
        if: github.event_name == 'pull_request' && github.event.action == 'closed' && github.event.pull_request.merged == true

I also separate out the push/pull workflows into separate files.

[fernandodlhdt]

This is what I was looking for. Thanks!

[thanhn1012]

It’s work for me

on:
  pull_request:
    types: [closed]

[ghost]

If you close a PR because you reject, it gets deployed so. NO!!!

[nickbenedetti]

This can not work as expected. If the PR is closed without merging, the action will still run.

[nickbenedetti]

When I say “this” I mean:

on:
  pull_request:
    types: [closed]

That code only looks for PRs that have been closed - and a merge is not necessarily a close - a PR can be closed without merging - so it’s not sufficient to guard against that case. I prefer:

on:
  pull_request:
    branches:
      - deploy
    types: [closed]
jobs:

<job id>:

if: github.event.pull_request.merged == true

steps: // the rest of the code

[jbnjohnathan]

I think this is the best solution
I changed to only use
if: github.event.pull_request.merged == true since I already filtered on pull requests in the on: part

[minherz]

The original request was to trigger an event on merge action. Using closed type of pull_request action triggers a workflow after the merge took place.

[nturnerlivanova]

A merge always closes the pull request. With his example, after the merge takes place it is closed then the workflow fires based on his example above. However, as noted at the top using a push would fire after the merge took place. https://docs.github.com/en/[email protected]/actions/using-workflows/events-that-trigger-workflows#running-your-workflow-when-a-pull-request-merges

However, running on closed is better as you know the PR merge was successful and occurs immediately after. Both are the same result if the branch is protected ( referring to only push )

[brennerm]

Hey folks, I wrote a little blog post + showcase repo that explain how to execute a certain job or step only if a PR has been merged and not just closed. Hope that helps 🙂

[biske]

This solution with the restriction to directly push commits to master solves the problem.

[okainov]

Which "this solution"?

[umermughal]

this solution means
Use push and restrict main/master branch from direct commit.
on:
push:
branches:
- main

hope I'm not wrong 😄

[hannesmnagel]

No, when you want one workflow to be triggered on merge of a pull request than making changes to it and then pushing on it, it would trigger itself. If it was possible to only execute it on merge of a pull request you wouldn't need a flag or date value to check wether it triggered itself and stop execution

[hamidelmaazouz]

@hannesmnagel what are you on about ? how "trigger itself" ? what flag or date value ?

[diego-discovery]

This is exactly what I was looking for. Thanks, Jen!

[ashish-laddha-jdas]

What if the workflow requires inputs before running? After PR merge, how is one supposed to get the inputs?

[BoHuang2018]

I prefer this solution. Most obvious

[renatojobal]

The documentation shows exactly that in this example: Events that trigger workflows - GitHub Docs

[minherz]

Are you sure about that documentation shows triggering a workflow on merge (and not after merge)? The language is a little obscure. It is unclear whether the "To run a workflow when a pull request merges, use the pull_request_target closed event type..." means that the event will be triggered before the merge is completed or after. In former case, if an action in the trigger fail, it should block the merge. In latter case, it makes no difference to the merge.

In my case, I want to run a couple of resource consuming e2e tests a minimal number of times. To achieve this I would like to run these tests only once before I merge PR into the target branch. And if the test(s) fail then to block the merge.

Reading the doc you linked it seems that the trigger happens on the fact of the merge. It means I cannot block the merge if my tests fail.

[leeyyl]

@minherz Do you think of a solution to solve the issue that triggers workflow before merge action is finished?

[minherz]

@leeyyl I do not see a way to implement it with the existing set of actions. I would like to have an action that happens right before the "merge commit" to a branch and if a workflow that is triggered by this action fails, the action should fail too. This variant would be ideal. Existing actions either too wide (e.g. on commit action), aren't blocking (e.g. push action with a type "closed") or do not fit description, like push acttion with the "synchronized" type (see another comment in this thread).

[VictorQueiroz]

The new correct link is:

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-pull_request-workflow-when-a-pull-request-merges

[derekgreer]

Here’s what our team is doing:

name: Build
on:
  push:
    branches:
      - "**"
      - "!main"
pull_request:

branches:

- main

types: [opened, synchronize, closed]
workflow_dispatch:
jobs:

build:

if: (!(github.event.action == 'closed' && github.event.pull_request.merged != true))
...

This triggers the build in the following cases:

• PR when opened, updated, and merged
• Non-PR pushes to any branch except main (which are covered by above case)

The job condition says “Run this for everything EXCEPT non-merged closed PRs”.

[pauliusguzas]

What benefit does adding github.event.action == 'closed' give, I think you could just add if: (github.event.pull_request.merged == true)

[jakubkeller]

A merge technically encompasses a commit “push”, targeting a specific branch (i.e., main). If you don’t target a branch, the workflow would trigger with any, including main. It’s like if you were to merge a feature branch into main locally and then push main to remote; all done on the remote in this case. This is exactly what the workflow team was thinking as well. This makes complete sense.

[minherz]

@jakubkeller so, forbidding push to the branch like in the (marked as answer) comment makes all "push" actions to be "PR merges", right?

I could not find documentation about what happens to PR if that push fails because the on-push triggered event fails to complete. Is it documented somewhere? I am asking because the observed behavior can easy change due to modifications to the platform.

[zerofirework]

I have the same concern as @minherz where I'd like to run integration tests and screenshot tests only before merge because they are very expensive if triggered on every PR update. It's too late to run if the test runs after they are merged to master.

[gilesw]

Completely, there's some things that you would like to run before code gets into main but not on every commit.

[acjay]

Maybe put another way, it would be great to have pull request merges work as transactions, with a mechanism to have failing workflows cause the transaction to rollback. Besides expensive tests, this could also be used to validate successful deploys. (The deployment process would have to be carefully designed to roll itself back.)

Without this capability, it gets pretty complicated. I've never set something up like this myself, but I feel like you have to do something like "CommentOps", where you create a state variable to represent if a workflow has succeeded on the latest commit, you create a check that blocks merge of that state variable is false, you trigger that workflow with a comment, and you rerun the check when the workflow successfully completes.

Maybe there's a better way to do this that I'm not aware of!

[zerofirework]

Since I posted my comment, I realize GitHub is about to release a new feature called merge queue. Looks like we will get a new event "merge_group" to trigger a set of tests before the PR is merged. I haven't tried it since the beta test has ended. Can someone help me confirm whether my assumption is correct?

[acjay]

Awesome, yeah, I think that's exactly what I want. I don't think there's any reason you couldn't deploy on the merge_queue event, as long as you build a way to roll back if the deployment failed.

[say8425]

on:
  pull_request:
    branches:
      - main
    types:
      - merged

madness. I just want it.

[paint-it-green]

@say8425 have you already tried this? https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-pull_request_target-workflow-when-a-pull-request-merges

[say8425]

@paint-it-green I already well know it, I just hope simple syntax.

[adrianbastholm]

I have the following:

  pull_request:
    types: 
      - closed
    branches:
      - 'main'

and

jobs:
  bump-main:
    name: 'Bump version on _main_'
    if: ${{ github.event.pull_request.merged == true && contains(github.event.pull_request.labels.*.name, 'HOTFIX') }}

I hope it helps someone

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

[realkingisback]

Just want to add my 5 cents:
in my case I wanted to build and run my tests on all branches but connect to dicker-hub and build&push image only when it's main

the solution was just to add the following if condition for docker related steps, like:

      - name: Login to Docker Hub
        if: github.ref == 'refs/heads/main'

      - name: Build and push Docker image
        if: github.ref == 'refs/heads/main'

[fspaniol]

I wanted to also add my particular use case. I own a repository that is used as a flux source for kubernetes deployments.

I have multiple different services running and I want to be able to send out notifications when a service is about to be deployed (which happens upon pushing to main). The caveat here is that since I have merge-queue enabled, more than one PR can be merged at the same time, and on: push will only consider the latest PR's squashed commit as the HEAD.

I only notify updates based on the services touched by the commit which is responsible for triggering the event, so the merge-queue defeats it (I know that an option here would be to limit the merge-queue to 1 PR at a time, but should it come to that? and also need to consider that depending on the time it takes on the merge-queue tests this could already be a bottleneck in itself).

The alternative that I have already played around with are by parsing the ${{ toJSON(github.event.commits) }} property, but this quickly became a rabbit hole.

The other use case I have is that depending on given labels from a PR, I want to perform some specific actions or not. On-push triggers don't really have a connection between the commit itself and which PR generated it (we restrict pushes to main, so it's guaranteed that it can only come from a PR). How to achieve that? For now I simply try to list the PRs that have been recently merged and try to pair with based on the list of files changed.

All that being said, I reckon I could change the approach to use:

  pull_request:
    types: 
      - closed
    branches:
      - 'main'

And leverage the github.event.pull_request.merged == true if condition on every step, but I believe something more standard should be offered.