// the find
dorny/paths-filter
Conditionally run actions based on files modified by PR, feature branch or pushed commits
A GitHub Action that detects which files changed in a PR, push, or branch, then exposes per-filter boolean outputs so you can conditionally skip jobs or steps. The core use case is monorepos where you don't want the backend pipeline running because someone updated a README in the frontend folder. Three thousand stars says this is solving a real pain point.
The filter DSL is genuinely well-designed — YAML anchors, added/modified/deleted type discrimination, and the `predicate-quantifier: every` mode for exclusion patterns cover the edge cases that naively glob-based solutions miss. For PRs, it uses the GitHub REST API rather than a git checkout, meaning the detecting job doesn't need to clone the repo at all, which saves meaningful time. The `list-files` output modes (csv, json, shell, escape) make it composable with downstream linting or processing steps without bashing out string manipulation in YAML. v4 targeting Node 24 shows the maintainer is keeping up with Actions runner deprecation cycles rather than letting it rot.
The compiled `dist/index.js` is checked in and must be manually rebuilt before each release — a common GitHub Actions antipattern that means the source and the running code can silently diverge if someone forgets the build step. The `predicate-quantifier` naming is opaque; 'every' vs 'some' describe set logic but the docs need a worked example to make the behavior clear (they provide one, but buried in a collapsed details block). There's no caching of the file-change list across steps in the same job, so if you run this action twice in one workflow it makes two API calls. In very large monorepos with thousands of changed files, the GitHub API pagination could become a bottleneck, and there's no documented behavior around what happens when the file count approaches GitHub's per-PR limit.