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
P
Pete Long
Hi there! This feature on path filtering is super intriguing! I’ve often wondered how targeting specific paths could streamline our workflows. How do you see this impacting CI/CD efficiency overall? I’d love to hear more about real-world applications! geometry vibes