Path filtering does not work for merge_group triggers

[wjglerum]

Select Topic Area

Product Feedback

Body

We are using this workaround listed here to handle skipped but required checks on pull requests
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks

That all works fine for pull requests, but now we would also like to use this for our merge queue. It looked liked it was working, however the path filtering doesn't seem to work for merge_group events. Both the normal and skipped workflow are now triggered in parallel

See below for more info:

• https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#merge_group
• https://github.blog/changelog/2022-08-18-merge-group-webhook-event-and-github-actions-workflow-trigger/

It does seem to work for branch filters as mentioned above. How would we handle skipped but required checks in our merge queues?

[jackson-miller-tbol]

We do something similar, except we have a single workflow that handles skipping for multiple other workflows. To get around the issue, we run a job to check the paths and then add a condition to the existing workflow based on that. It does create another job, which adds another status to the PR (which I'd like to avoid) and adds a little time to the workflow.

It looks a bit like this:

name: My workflow
on:
  merge_group:
    branches: ['main']
  pull_request:
    branches: ['main']
    paths:
      - '.github/workflows/this-workflow.yml'
      - 'some/path/**'
      - 'even/more/path/**'

jobs:
  # We need this because merge groups dont support path filters
  # https://github.com/community/community/discussions/45899
  changes:
    name: Determine if we need to run the workflow
    runs-on: ubuntu-latest
    outputs:
      changesFound: ${{ steps.filter.outputs.changesFound }}
    steps:
      - name: Checkout source code
        uses: actions/checkout@v3

      - uses: dorny/paths-filter@v2
        id: filter
        with:
          filters: |
            changesFound:
                    - '.github/workflows/this-workflow.yml'
                    - 'some/path/**'
                    - 'even/more/path/**'

  test:
    name: Main Workflow
    runs-on: ubuntu-latest
    needs: changes
    if: ${{ needs.changes.outputs.changesFound == 'true' }}
    steps:

[ghost]

Hitting the same issue here where we're using merge queues in a mono-repo. We are using path filters on pull_request event triggers successfully to ensure we're only running the CI/status checks for the components under change. When we extend this to merge_group triggers to get the required status checks to pass prior to merging for only those components under change we effectively have all our CI running for all our components. There's some irony here somewhere that this doesn't work for mono-repos where contention for merging is going to be at its highest.

[karadikidd]

We're also using path filters to determine which workflows to run. However, in our case, when we click the "merge when ready" button before our CI workflows have completed, they are bypassed, and the PR is instantly added to the queue.

Furthermore, we have observed that the merge queue does not execute any CI workflows, ultimately resulting in changes being merged without undergoing any testing.

[Yehonal]

Any updates here from the GitHub team? are the path filters going to be supported soon?

[alex-statsig]

Also running into this issue, had to switch to merge_group because the previous trigger of "push to .../readonly/..." stopped working for us today. This is a pretty critical flaw in merge queue at the moment, as we are now being billed / wasting ~10x the minutes/runners etc.

[antonyc]

Probably the solution dorny/paths-filter#183