Action with both branch and path wrongly triggers on push

[adelinn]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

I have an action with this configuration:

name: On push workflow with path and branch

on:
  push:
    branches:
      - main
    paths:
      - 'some/path/**'
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: sleep 10

According to the docs (If you define both branches/branches-ignore and paths/paths-ignore, the workflow will only run when both filters are satisfied) it should trigger only if I push a commit with a change to a file in that path.

When I committed this file the workflow triggered. Why??? In fact I experienced workflows triggering when committing files to the main branch that have nothing to do with the paths in the workflows that dot triggered.
I reproduced the issue in this public repo: https://github.com/bcc-code/test-repo/actions/runs/26511986861
I didn't manage to reproduce it when a different file changes though, as my original issue is.

This looks like a bug!

[P-r-e-m-i-u-m]

I looked at the public run you linked. The run was a push event on main, and the commit only changed this file:

.github/workflows/on-push.yml

So your reading of the documented rule is right: when branches and paths are both set, both filters should be satisfied for a normal push path match.

The confusing part is that the pushed file is the workflow file itself. I would test this separately from workflow-definition changes, because workflow-file creation/updates can behave like a special case in Actions. In other words, this reproduction proves “updating the workflow file caused the workflow to run,” but it may not prove that unrelated application files outside some/path/** will trigger it.

I would narrow it down with three commits:

1. Commit only README.md on main.
2. Commit only other/path/file.txt on main.
3. Commit only some/path/file.txt on main.

If #1 or #2 triggers the workflow after the workflow file is already present and unchanged, then I would treat that as a likely Actions bug and send those exact run links to Support. If only #3 triggers, then the path filter is working for normal file changes and the odd behavior is tied to modifying .github/workflows/on-push.yml itself.

Docs:

• Branch and path filters together: https://docs.github.com/actions/reference/workflows-and-actions/events-that-trigger-workflows#running-your-workflow-only-when-a-push-affects-specific-files
• Workflow syntax for paths: https://docs.github.com/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore

[adelinn]

I just tried making the exact same commit in a private repo where this happened with an unrelated file and it no longer triggered workflow runs. This is very strange.

[cdkh]

I would like to chime in here since we observed somewhat the same bug yesterday:

We have one repository with about eight actions. We did a commit and six out of the eight actions, which barely run, triggered. Supposedly it should have only been one action. All actions with only the workflow-dispatch-trigger, did not trigger. Actions, that had a paths segment, did trigger, even when the paths part did not match.

This might be related to the degraded action / pages performance that was reported the day before yesterday.

For one repository the overview page of the repository suddenly showed there was a webpage again we hosted from the repository, which was a long time ago.

Speculative:
I can only guess, but maybe this incident did require a reset of the action-database. If actions do store a "run on last commit" variable and this was wiped, any commit would have resulted in a check, that would dig through a lot more commits - matching a lot more paths. For the repository I mentioned earlier, some actions did match folders that did not change for the last three years.