2

I'm trying to reduce the amount of files I have for my workflows from 4 to 1. And with that my on is like this:

on:
  pull_request:
    types: [opened, synchronize, closed]
  push:
    branches: [master]

I know it's possible to use if in workflows but looking at the documentation I didn't find which parameters I should use to trigger the correct jobs when:

  • Pull request is opened
  • Pull request is closed
  • Push is made to a existing pull request
  • Push is made to a brach
TheOneFromBrazil
  • 43
  • 7
  • 3
    Check out this [answer](https://stackoverflow.com/questions/62325286/run-github-actions-when-pull-requests-have-a-specific-label/62331521#62331521) of mine for something similar, where I have provided a sample event payload too. Essentially you need to use `github.event.action` in the `if` condition. For eg `if: ${{ github.event.action == 'opened' }}` – Madhu Bhat Aug 06 '21 at 12:35
  • 1
    You can enable a webhook on GitHub for different events and check what's the value that comes under `github.event` for each event and based on that have conditions for whichever events you need. – Madhu Bhat Aug 06 '21 at 12:36

1 Answers1

-1

The piece of documentation that touches on how to use if is this one.

You can use it at the job level. Consider the following example to execute a job only when the PR has been closed and merged (not just closed):

name: Build Your App

on:
  pull_request:
    types: [ closed ]
    
jobs:
  build:
    # this job will only run if the PR has been merged, not just 'closed'
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:

    - name: Checkout repository
      uses: actions/checkout@v2
      with:
        fetch-depth: '0'

And you can also use it at the step level, to execute or not the step based on the {{ expression }} evaluation, as the documentation shows.

Based on your ask, I would use the information on the github.event.* payload. To do that I use to re-create the conditions and triggers on a test repository and print it to the console. Then I know what I have to look for in each kind of event. It's like debugging the events. This is the documentation to do that.

M. Gleria
  • 468
  • 5
  • 14