The path-filtering orb is a very versatile orb that allows you to continue a pipeline based on the paths of changed files.
This article is to help show some examples of what can be achieved using the path filtering orb using some examples with links to each of the projects which have their own explanation of how they have been configured.
This is a simple example showing how to use path filtering to pass a parameter to choose which jobs to run on the continuation config.
This example only uses two files and only allows you to choose which workflows to run based on the parameters that are set to true on the first config.yml. These are then checked when using the orb to run the continued config from the second config file.
This second example uses mapping to allow multiple different continuation files to be used.
In this sample project's.circleci/config.yml, we "break" the path-filtering/filter job down, and add a step in the middle to choose the right continued config.
Based on the files which are changed only the matching continue-XXX.yml will run as it will be passed in as the config key.
The final example implements both path filtering and config splitting.
The final example uses a list of directories, to detect which subdirectories (herein modules) have changed.
It will then fetch the
path-to-module/.circleci/config.yml for each module to build, and merge all the fetched
config.yml along with the config defining common resources, i.e.,
.circleci/config.yml and finally execute the merged config.
It's important to note that
base-revision dictates the branch by which the code changes are compared against. These changes are cumulative, so in a scenario where a branch with
base-revision: main has had many commits and changes, you may find that more workflows are triggered than desired. If you want to see workflows triggered for new changes, consider setting
base-revision: << pipeline.git.branch >> so that the branch pipeline compares the changes to itself.