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.

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

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

[thanhn1012]

It’s work for me

on:
  pull_request:
    types: [closed]

[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

[sp185503]

I’ve tried the above but the workflow or Step is always skipped. Has something changed?

[sp185503]

Actually… using @nickbenedetti’s example worked. Had to follow it exactly.

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

[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

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

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