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
D
Dan Gaskin
Pete Long I can speak for myself as Minjun raised this on my behalf. We effectively have a mono repo that isn't one size fits all in terms of requirements and therefore not under one package manager.
That means we may make a change in one small isolated part of the code base, but the entire pipeline then runs with a load of path filtering and effectively dead time before the relevant build takes place bloating time. We see path filtering as sort of a matrix before the pipeline starts to ping point what needs building. More so, it should allow us to do more parallelism with better dependency management between steps for more cross cutting things.
We do this a bit with github actions and it works well, but we find circle a far better build system and would prefer to move things there.