Depends the CI software obviously but for Azure DevOps/VSTS, they have just what you describe and seem to call it "triggers": https://docs.microsoft.com/en-us/a

Depends the CI software obviously but for Azure DevOps/VSTS, they have just what you describe and seem to call it "triggers": https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml https://docs.microsoft.com/en-us/azure/devops/pipelines/buil... I have seen similar things in other CI providers but basically you have two options: 1) Use a monorepo and filter out which steps or when to run the CI based on the conditions you describe using the features of the CI software. 2) Split up the repo and give each repo its own CI which runs when files in the subrepo change. For example the frontend CI would run the frontend tests and compile a static file which could just simply be downloaded by the main build. Both will speed up your CI process, which one is best depends a lot on your application architecture and build and deployment process.