pull_request action does not run on merge

I upgraded to the new GitHub Actions released last week with the YAML syntax. My action – which uses on: pull_request – no longer seems to run when a Pull Request is merged. Previously, this would trigger a run with the payload’s .action equal to closed, which is exactly what I want. After the upgrade, it just doesn’t run.

Note that if I manually close the Pull Request without merging, the action fires as expected.

Is this By Design? Should I switch to using the branch close event type? That would be a bit unfortunate given that I’d now need to duplicate some workflow logic, but certainly seems like a workaround at the very lease.

Thanks. Full workflow below:


name: Pulumify  
on: pull\_request  
jobs:  
  updateLivePreview:  
    name: Update Live Preview  
    runs-on: ubuntu-latest  
    steps:  
      - uses: actions/checkout@master  
         if: github.event.action != 'closed'  
         with:  
            ref: ${{ github.event.pull\_request.head.ref }}  
            fetch-depth: 1  
      - uses: pulumi/actions-pulumify@master  
         env:

    ...  
9 Likes

In your sample workflow you have: if: github.event.action != 'closed', in other words your workflow step will  not run when the action is closed. When a pull request is merged, the event triggered has an actionof closed and a pull_request.merged value of true, so your sample workflow would not match. This is the expected behavior.

If you want to match only pull requests that have been merged, you can use if: github.event.pull_request.merged.

I hope that helps!

We have the same issue, albeit without setting a condition.

PRs that are created, synchronized, etc… trigger an Action. However, when a PR is closed, the Action is not triggered anymore.

It worked earlier with the HCL syntax, however since the new YAML workflows have been announced, the behaviour of our HCL workflow also changed so that closed PRs didn’t trigger Actions anymore…

3 Likes

Same here. Our workflow has no conditions, yet is still not triggering on ‘pull_request’ ‘closed’.

Here’s an example pull request that was closed:
https://github.com/WordPress/gutenberg/pull/17157

The checks tab still shows the check from when the pull request was opened. There’s some logging in the ‘pull-request-automation’ action that shows this is the case:
https://github.com/WordPress/gutenberg/pull/17157/checks?check_run_id=201154358

In the repo’s actions tab, the list of actions is only showing jobs where ‘user created a pull request’ even when that definitely wasn’t the case:
https://github.com/WordPress/gutenberg/actions

I’ve also noticed that things like pull_request edited or labeled does not trigger the workflow either.

2 Likes

Same here. The webhook I’m looking for (without the irrelevant info):

headers:
X-GitHub-Event: pull_request

payload:
{
  "action": "closed",
  "pull_request": {
    "merged": true
  }
}

My workflow:

name: CI

on: [pull_request]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - name: Pull request merged
      if: github.action == 'closed' && github.pull_request.merged == 'true'
      run: echo merged

And it simply does not get triggered at all, even if I would remove the if condition.

Use case: purge the pull request deployment.

Getting this fixed would be super useful for the workflow we have in mind (label a PR, auto merge it).

5 Likes

Hi @joeduffy! I am on the product team for GitHub Actions.

You’re seeing this behavior because the default activity triggers for pull request are opened, synchronize, reopened. In order to fine grain control which PR events you want to trigger your workflow, definitely check out Triggering workflows for PR events and scroll down to the full event list.

For example if you want to trigger your workflow on PR close, you will need to use the following YAML

on:
  pull_request:
    types: [closed]
23 Likes

I’ve been eagerly waiting for this feature to be implemented the last 3 weeks or so, thanks a lot! Now we can finally switch to the new action model! Thanks a lot! 👍

@amq just complementing, the other answers… your “if” condition needs “event” object, it could be:

name: CI

on:
pull_request:
types: [closed]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - name: Pull request merged
      if: github. **event**.pull_request.merged == true
      run: echo merged
3 Likes

Thanks for fixing this, I’ve tried it and works as expected

Would it make sense to have a PR event of merged?

10 Likes

Hi,

I am using

on:
  pull_request:
    types: [closed]

for my workflow trigger, without any conditionals, but it is still not triggering when a PR merges. The PR is being merged by a different GitHub Action that merges it using GitHub API with

uses: actions/github-script@0.2.0

Could that be a reason it wouldn’t trigger?  If I manually merge a PR, it triggers as expected.

I’ve also tried

on: push

where the merge does a push, but same results. A manual merge triggers the workflow based on push, but the merge via API and the github actions bot does not trigger the workflow in question…

2 Likes

I have the exact same problem as @rcasperson-jc:

Manually merging a pull request triggers my Action, but using the Github API in an other Action to merge a pull request does not trigger my Action.

The only difference I can see is that the merge in the latter case is done by the user github-action (bot).

Is it by design / a limitation / a bug of Github Actions?

Okay I figured out why my Action wouldn’t start.

As stated in the doc: “An action in a workflow run can’t trigger a new workflow run” (Events that trigger workflows).

I had a script in a step that did some changes to my repo with the ${{secrets.GITHUB_TOKEN}} parameter. I expected those changes to trigger another workflow but  they didn’t.

By using a personal Github token instead I was able to make it work because now the user responsible for repo changes is not github-actions who obviously cannot trigger workflow, but me.

Hope it’ll save some time to people

Any Success to fire the event for merge only ?

I can’t get pull_request to fire for anything. I’ve tried

on: pull_request

on: [pull_request]

and

on:
  pull_request:
    types: [opened, edited, read_for_review]

and none of those fire when I open a new pull request or edit an existing one.

How about on PR merge? 

2 Likes

This is weird, because I think it would be the most important to have. On PR closed the workflow would be triggered also also in case we reject the PR which is not ideal.

So not sure if this is helpful but for the use case where you

a) Would like some tests to run when you (or one of your team) opens a PR
b) Would like to deploy the npm package when you merge the PR I have found the following works well.

In your .github/workflows directory have 2 files ci.yaml and cd.yaml

#ci.yaml (for running test on PR open, edit, reopen and synchronise)

on:
  pull_request:
    types: [opened, reopened, edited, synchronize]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 12.x
        uses: actions/setup-node@v1
        with:
          registry-url: https://npm.pkg.github.com/
          node-version: 12.x
          scope: "@{your-scope}"
      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test

#cd.yaml

on:
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 12.x
        uses: actions/setup-node@v1
        with:
          registry-url: https://npm.pkg.github.com/
          node-version: 12.x
          scope: "@{your-scope}"
      - name: npm install and build
        run: |
          npm install
          npm run build --if-present
      - name: publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
        run: |
          npm run deploy

Has the added benefit of deploying the package if an admin bypasses the PR process for an urgent hotfix type scenario.

Hope this helps