on.pull_request.paths-ignore are not respected correctly

[GRBurst]

Describe the bug

According to the documentation we can use paths-ignore in the same way for pull_request events as we can do for push events on.<push|pull_request|pull_request_target>.<paths|paths-ignore>.

However, if we define a workflow like the following, the behavior differs:

name: Echo Date

on:
  push:
    paths-ignore:
      - 'README.md'
  pull_request:
    types: [opened, synchronize]
    paths-ignore:
      - 'README.md'

jobs:
  echo-date:
    runs-on: ubuntu-latest
    name: "Echo"

    steps:
      - name: Run echo date
        run: |
          echo -e "Hello at $(date -I)"

Although it seems to be working at the beginning when I (1) created a pr, (2) pushed a change on README.md and (3) nothing triggered, the behavior changed as soon as one commit of the pr references a file outside of the paths-ignore list.
After a change to a file outside of the paths-ignore list, all following commits trigger the workflow.

Someone else mentioned a problem here as well: #545 (comment)

To Reproduce
You can find a minimal example here: https://github.com/GRBurst/pull_requests.paths

Steps to reproduce the behavior:

1. Create an action as above (or fork the example)
2. Create a new branch and a pr
3. Add commits, where at least one commit changes a file outside the paths-ignore declaration
4. Check that all following commits trigger the workflow (the pull_request events triggers, the push does not).

Expected behavior
I expect that the conditions to run the actions only take the last commit into account.
So if I have commit that changes a file outside the path definition, it triggers the workflow.
If a following commit does only changes to files declared in the paths-ignore list, the workflow should not trigger.

Runner Version and Platform

Version of your runner?
-> 2.299.1

OS of the machine running the runner? OSX/Windows/Linux/...
-> Ubuntu, 22.04.1, LTS

[rene-hermenau]

Can confirm the bug

[nickfujita]

Confirmed when trying this Github suggested solution in the troubleshooting docs:
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks

[ShutdownRepo]

I also confirm this bug.

[zdenko-kovac]

I can also confirm the bug:

Workflow: https://github.com/zdenko-kovac/testing/blob/main/.github/workflows/testPR.yaml
PR with 3 commits: zdenko-kovac/testing#2

where:

• initial README.md update didn't trigger the WF (correct)
• update of the WF itself (outside of paths-ignore): triggered the WF (correct)
• additional update of README.md triggered the wf (wrong)

[kingthorin]

It's been half a year, any news on this?

[ilyesAj]

as a work around you can make :

  pull_request:
     paths:
       - '!docs/**'
       - '.github/**'

[mmulligan03]

Is there an update on this issue? Has anyone developed a workaround?

[pavetok]

It seems pull_request.paths affected too.

[qrkourier]

Is there an update on this issue? Has anyone developed a workaround?

@ilyesAj's workaround to negate paths patterns didn't work for me. I tried it the way they wrote it, and I tried it like this because the workflow syntax reference indicates that negations may only subtract from selected paths. The result of both workaround attempts was that no pull request event types triggered the workflow irrespective of change objects matching the paths filter patterns.

  pull_request:
     paths:
       - '**'
       - '!docs/**'
       - '.github/**'

[wallyrion]

Also, I have a similar issue in my project.
Paths working for 'push' but not working for 'pull_requests' This workflow always runs when new changes are added in a pull request regardless of the changed path

on:
push:
branches: ["refactoring/move-to-separate-solutions"]
paths:
- "TwitPoster.EmailSender/"
pull_request:
branches: ["master"]
paths:
- "TwitPoster.EmailSender/"

[deleugpn]

According to this explanation https://github.com/orgs/community/discussions/25161#discussioncomment-3246673 this "bug" is by design. Apparently when we make the on: pull-request actions, it will automatically use the synchronize event which will always consider all commits of a file change.

Although understandable, I think what we're missing here is a different implementation of the on: pull request functionality. If we had something like:

on:
  pull_request:
    types: [pushed]

Perhaps the pushed event could work differently than the synchronize event and thus not creating a huge breaking change effect. This way we could have a setup where we only run GH Actions based on pull requests events that includes a push of a commit, but also offers path filters on the most recent commit only. After all, if I have a deployment action and I'm only changing docs file, it doesn't matter that previous commits made changes to the real code, I still don't want to re-run all my deployment and pay for GH Actions when there's clearly no functionality change.

[munapower]

I have a similar issue. I have defined a workflow with the following:

name: Update Documentation
on: 
  push:
    paths-ignore: 
      - '.github/workflows/**'
      - "!**.md"
  pull_request:
    paths-ignore: 
        - '.github/workflows/**'
        - "!**.md"

When I push a change of the yaml that contains this code it doesn't execute. This is expected. Then I made a change to "samples/chaincode/echo-go/chaincode/echo.go" and pushed it and the workflow did run. I understand that it shouldn't have since the "!**.md" would have been true, right?