Parallelization is an important capability for CI frameworks. Servicer should allow its users to leverage the CI platoform he is running Servicer on. This would include spinning up separate nodes/VMs to address different tasks, which is particularly valuable for monorepos. To facilitate this, Servicer could add a flag that would have Servicer return a list of services within the repo that have changed since the last time Servicer tagged the branch, rather than running all steps (appropriate for the active branch) for all services.
For example, say you have a monorepo with three services: foo, bar, and wizz. These watch_paths are foo/*, bar/*, and wizz/*. On the active branch, Servicer has already run twice, so has git-tagged this branch. The developer edits files within the bar and wizz directories, then runs servicer --changed-services. Servicer will perform the git-diffs and return the names of services that have been changed: bar, and wizz.
This will allow any Servicer user to then use their UI platform to parallelize work for the services. In the example above, a Jenkinsfile could provide parallel stages for each service that was edited. Within each stage, it would simply run the steps for the relevant service. Ex:
stage('foo') {
sh 'servicer --service=foo'
}
Parallelization is an important capability for CI frameworks. Servicer should allow its users to leverage the CI platoform he is running Servicer on. This would include spinning up separate nodes/VMs to address different tasks, which is particularly valuable for monorepos. To facilitate this, Servicer could add a flag that would have Servicer return a list of services within the repo that have changed since the last time Servicer tagged the branch, rather than running all steps (appropriate for the active branch) for all services.
For example, say you have a monorepo with three services: foo, bar, and wizz. These
watch_pathsarefoo/*,bar/*, andwizz/*. On the active branch, Servicer has already run twice, so has git-tagged this branch. The developer edits files within thebarandwizzdirectories, then runsservicer --changed-services. Servicer will perform the git-diffs and return the names of services that have been changed: bar, and wizz.This will allow any Servicer user to then use their UI platform to parallelize work for the services. In the example above, a Jenkinsfile could provide parallel stages for each service that was edited. Within each stage, it would simply run the steps for the relevant service. Ex: