I don’t see the workflow you linked to anymore. Is this still an issue? If so, can you tell me which workflow is the one you’re having a problem with?

Thanks.

Here is a more recent commit: SamChou19815/website@1a1643a

and workflow files at that point:

https://github.com/SamChou19815/website/tree/1a1643a643b764337626b8a16d05fe56d8bae913/.github/workflows

Since I made a change in the main-site-frontend folder in master, I would expect this workflow to run based on the path config: https://github.com/SamChou19815/website/blob/1a1643a643b764337626b8a16d05fe56d8bae913/.github/workflows/generated-cd-main-site-frontend.yml but it’s not run.

You expect that pattern to cover arbitrarily-nested directories, right?  I tried it out earlier, and I don’t believe that’s supported right now.

'main-site-frontend/**'

Try changing the above to

'main-site-frontend/*'

I have tested using only one asterisk and it gives the same result as two asterisks. Only files directly in the folder will trigger the action but not a file which is nested, for instance: main-site-frontend/another-folder/changed-file.txt will not trigger the action

I think that the pattern is using Go Path, which does not seem to have any support for nested directories.

I checked the Go path discussions and it seems to have gone anywhere to being supported. This fundamentally becomes a maintenance issue. I had to use a bunch of ‘path/*’, ‘path/*/*’, etc… pasted over and over again to get the result I wanted. However if someone were to add one more nested folder than my configuration and forgets to change the workflow file, it will not get triggered.

@svalluru-aaiis right, Go path.Match does not support matching nested directories.

On GitHub’s docs there is a section on how to support sub-projects by listing as many nested path’s as possible which is a downright hack.

This feature is crutial in supporting monorepos and would be amazing if it worked out of the box for such usecases.

Would it be possible to switch from path.Match to something like regex? This would enable much more versitile rules and the Go standard library already comes with regex in the standard library.

I’m currently evaluating moving more of our CI/CD workload to GitHub Actions. Our project is a Monorepo with more than 100 nested projects. It would be extremly helpful if I could add 

**/*.js

to match ALL JavaScript files in all subdirectories.

Right now I’m using this instead:

*.js
*/*.js
*/*/*.js
*/*/*/*.js
*/*/*/*/*.js
*/*/*/*/*/*.js

This will trigger when changes happen to any JS file nested 5 levels deep. The workflow file gets very hard to read, though.

Any idea about the timeline when the feature will land?

We are working on an update to the path matching that will support the more standandard globbing patterns.  Please keep an eye on the GitHub changelog for the update.

Here it is!!!

https://github.blog/changelog/2019-09-30-github-actions-event-filtering-updates/

Unfortunately, when I type paths-ignore, Github is complaining about it, not working.

Sorry, it is working but auto-suggestion of Github is complaining about the syntax that’s why I though it is not valid. I am so sorry 😦

How can we debug path matching? Currently if the workflow doesn’t start, we’re just left staring at the Actions screen with one big question: WHY?
Can we somewhere get a log of how the changed files in a commit are matched against the paths?

Or, for that matter, the inverse - why did a workflow run when it should not have? It would be nice to see a list of files, filters they matched and the workflow decision.