Path filtering at the trigger level
Minjun Seong
Problem:
We have a large monorepo without a package manager, and we rely on path filtering to run the right jobs for the right parts of the codebase. Today, path filtering happens inside the pipeline YAML (via dynamic config and the path-filter orb), which means we end up with a single, long, complex pipeline.
Suggested Solution:
Allow path filters to be configured at the trigger level in project settings — alongside the existing branch and tag filters — rather than requiring them inside the pipeline YAML.
This would let us define multiple triggers, each scoped to a specific directory or set of paths, with each trigger pointing to its own focused pipeline config. For example:
services/auth/** → triggers the auth pipeline
services/payments/** → triggers the payments pipeline
libs/shared/** → triggers a shared-libs validation pipeline