How to trigger an action on push or pull request but not both?

[Nosferican]

I would like my workflow to be triggered by either a push or a pull-request, but if it a push to a pull-request only trigger one rather than two workflows.

Something like,

on: [push | pull_request]

[ethomson]

I’m afraid that you cannot do this directly.  However, you can trigger only on pushes to master, or pull requests to master.  This will prevent builds from happening twice when somebody opens a pull request against master and then pushes updates to their branch.  For example:

on:
  push:
    branches:
    - master
  pull_request:
    branches:
    - master

[acnicholls]

This workflow will only trigger on direct push to master, or on merge of PR that targets master. So, no you can’t edit the code in the PR and have this run. But you could reopen the PR, update it and then merge it again to trigger the workflow, i guess. Most devs would just open a new PR tho

[razvanphp]

How is it useful if you just run it after it's merged? The whole point is to test that nothing is breaking BEFORE merging the PR.

[eli-schwartz]

@razvanphp,

Useful to the kind of person that thinks devs who need to update a PR will just open a new one?

Or useful to projects in general?

[razvanphp]

If you break a test, you will not open a new PR, right? I mean in general.

[eli-schwartz]

Don't ask me, I wouldn't open a new PR either way.

A PR is a named pointer containing a high-level proposal. You attach changesets (patches) to it in an effort to resolve the proposal, and often the patches themselves change based on feedback -- there's no dedicated place separate from a PR to publish patches or compare the differences between versions (which is a shame since we could use one -- GitHub is very bad at this).

But the vast majority of developers don't know how to use either bug reporting systems or version control systems. They open a new PR because that is the only way they can figure out how to use the online GitHub code editor to commit alternative changes to a branch.

[heathsnow]

I found this while searching and thought some people might find my solution helpfull as well.  I have a workflow that has a ‘build’ job and a ‘deploy’ job.  I want to build pull request and deploy merges to master.  Here is my workflow setup:

name: 'foo'
on:
  push:
    branches:
      - master
  pull_request:
env:
  SOME_THING: sweet
jobs:
  build:
    runs-on: ubuntu-latest
    if: github.ref != 'refs/heads/master'
    steps:
      - name: 'Checkout'
        uses: actions/checkout@master
  deploy:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/master'
    steps:
      - name: 'Checkout'
        uses: actions/checkout@master

[Segelzwerg]

Thanks for sharing that solution. I have a follow up question. Is it possible to run actions on branches which have not been pull requested, but don’t run the push on the PR than.

Do you now what I mean?

[michaelmior]

Will this still run builds when the branch for a pull request is updated? That is, I understand the action will run when a pull request is first created for a branch. But if the action is only run for pushes to master, then does that mean it will not run for pushes which update a branch used in a pull request?

[lestephane]

The provided code does not work for me, I get

 Error
Invalid type for on

Here’s my yml

on:
  schedule:
    - cron: "0 10 * * *" # everyday at 10am
  tags:
    - "v*.*.*"
  push:
    branches:
      - master
  pull_request:
    branches:
      - master

What am I doing wrong? How do I troubleshoot? Thx

[fkirc]

I published https://github.com/marketplace/actions/skip-duplicate-actions to solve this problem.
You can give it a try if this is still an issue.

[pperzyna]

Solution:

on: 
  push:
  pull_request:
    types: [opened]

[Simran-B]

It does prevent additional runs caused by pull_request synchronize later as you push to the feature branch indeed. But doesn’t it still cause two workflow runs initially? (pull_request opened and push to feature branch)

[Borda]

This is a very important issue as you may use some automatization for merging… if you have N checks, created PR as repo owner creates 2N check compare to forked PR creates only N checks…
With limiting push/PR to master you miss all development/testing in branches even as repo owner 😕

[marcosfelt]

This works for me! Thanks @piersy!

[piersy]

@marcosfelt Did it really?

I thought it was working for us but it wasn’t actually letting the forked PRs run.

In fact I came to the conclusion that the “user:branch-name” branch names for forked PRs are a result of the way the github frontend displays branch names and do not actually represent a different class of branch name. In the case of non forked PRs I think github hides the “user:” prefix, because it is redundant. The branch name that is matched against by github actions will be the segment that follows the colon.

Please confirm if I’m incorrect otherwise I will delete the original post as I do not see any way to edit it.

We have now settled for a different solution:

on:
  workflow_dispatch:
  pull_request:

See - Run go workflow on manual trigger and all PRs by piersy · Pull Request #743 · clearmatics/autonity · GitHub

This runs github actions on all PRs and allows us to manually trigger workflows on arbitrary branches. This works out slightly better for us since we didn’t really want to run github actions on every push.

[piersy]

I deleted this post because it contained incorrect information, the solution I provided did not work and I receive confirmation from one other person that it was not working for them.

See this post for the current solution we have adopted - How to trigger an action on push or pull request but not both? - #13 by piersy

[jb185555]

I have found a work around to this:

My workflow has this at the top:

name: "Build"
on:
  pull_request:
    branches: [ master ]
    types: [ opened, synchronize, closed ]
  push:
    branches-ignore:
      - master
    paths-ignore:
      - README.md
      - CHANGELOG.md  # Should never be edited anyway
      - .gitignore
      - .github/**
      - Jenkinsfile

I have the following steps:

Get Branch Name:

      - name: Extract branch name
        id: extract_branch
        run: |
          echo ${GITHUB_REF##*/}
          echo ::set-output name=BRANCH_NAME::${GITHUB_REF#refs/*/}

Using a JS script (see below)

      - name: Check if Branch is in PR
        if: github.event_name == 'push'
        id: checkbranch
        uses: actions/github-script@v4
        with:
          github-token: ${{ env.GITHUB_TOKEN }}
          script: |
            check_branch_pr = require('./.github/scripts/check_branch_pr.js')
            return await check_branch_pr({github, context, core})
        env:
          GITHUB_USERNAME: ${{ steps.secrets.outputs.GITHUB_USERNAME }}
          GITHUB_TOKEN: ${{ steps.secrets.outputs.GITHUB_TOKEN }}
          GITHUB_ACTOR: ${{ github.actor }}
          GITHUB_EVENT_NAME: ${{ github.event_name }}
          BRANCH_NAME: ${{ steps.extract_branch.outputs.BRANCH_NAME }}

js script (GET request on Github API to see if the branch pushed is in a PR already)

module.exports = async ({github, context, core}) => {
    console.log(process.env.BRANCH_NAME)
    const resp = await github.request('GET /repos/{owner}/{repo}/pulls', {
        owner: context.repo.owner,
        repo: context.repo.repo,
    });
    if (resp.data) {
        const pullRequestsWithBranch = resp.data.filter(it => it.head.ref == process.env.BRANCH_NAME)
        console.log(pullRequestsWithBranch)
        return pullRequestsWithBranch.length >= 1
    }
    return false
}

Set output for the js script

      - name: Setup Output for Branch in PR
        id: inprcheck
        run: |
          echo '::set-output name=BRANCH_IN_PR::${{ env.BRANCH_IN_PR }}'
        env:
          BRANCH_IN_PR: ${{ steps.checkbranch.outputs.result }}

Using this if statement, you can make it so on_push skips all of the steps and exists successfully, but if you push a branch before a PR, the workflow will run as normal. Let me know if you have questions.

- name: foo
   if: steps.inprcheck.outputs.BRANCH_IN_PR != 'true'

[albertz]

Yea, I also have that problem.

But now while reading here, I reconsider why I actually have my CI triggered on both pushes and pull requests. The reason was that I definitely need CI on pushes to master. But I also wanted to have CI run on custom dev branches. And of course I want to have CI run on PRs.

The CI on custom dev branches are causing the two runs of CI because they are often also PRs at the same time.

But now I wonder if I really need the CI to run on any branch (except master). For any dev branch where I would want CI to run, I could just create a draft PR. Draft PRs basically solve this.

So now I use:

on:
  push:
    branches:
      - master
  pull_request:

[SpOOnman]

We’ve solved the same problem with this minimal configuration:

on:
  workflow_dispatch:
push:

paths-ignore:

- 'README.md'

This way:

• every branch is build on push without a need to create a PR
• when you create PR this “branch build” is already picked up by checks
• when you update PR it is build, because branch has changed
• master is build on branch merge after PR
• master should be build after push as well, but I didn’t check that since it’s restricted in our project.

[MatteoAlbi]

I find this option interesting. Can you please explain better what is happening? What does workflow_dispatch do in this case? Also i find the identation a bit confusing

[michaelmior]

workflow_dispatch just allows the capability to manually trigger a build at any time. It's not necessary to implement any of the points mentioned above. Really the only necessary part here is push: which specifies that all branches should be built any time something is pushed.

[spencer-hong]

I had the same issue and it was solved by using main instead of master.

[jonashonecker]

You can manage concurrent workflows using GitHub Actions' concurrency feature. By setting up concurrency at the workflow level, you ensure that only one instance of a workflow runs for a given concurrency group. This is particularly useful to avoid overlapping runs for the same branch or pull request.

For example, if you specify the following in your workflow file, it ensures that only one workflow associated with the same branch (or pull request) runs at a time:

concurrency:
  group: "your-group-name"
  cancel-in-progress: true

I got the inspiration for this solution in a helpful blog post by Maxime Heckel.

[PepijnB]

This action might provide the functionality you're looking for: https://github.com/fkirc/skip-duplicate-actions