I have a Visual Studio solution with multiple projects, each project is an individual microservice. It is very convenient to the development team to have all the services in the same solution, and git repo, as services can call each other.
Master.sln - SubFolderA - MicroserviceA.sln
- SubFolderB - MicroserviceB.sln
- SubFolderC - MicroserviceC.sln
I would, however, like to independently build/release the individual microservices in Azure DevOps when they change, so if ServiceA is the only service to change, then ServiceA is the only service built and deployed.
To this end I created a new build pipeline definition with "Path filters" set to trigger the build when the contents of a microservice folder change (so one path filter added per microservice to monitor).
My problem here is that when a build is triggered (based on a change to SubFolderA e.g.) I have no way to tell the build definition to only build the .sln file in SubFolderA.
I could create a separate build definition for each microservice and trigger each build on separate subfolders, but this would come at significant overhead, i.e. I would need to maintain 15 separate build definitions (same again for each branch I build), and the storage required on our self host build agent would now be NumberOfService x NumberOfBranchesBeingBuild x SizeOfRepo.
Is there a way to use a single Build Definition with git "Path filters" and multiple paths defined, which in turn kicks off multiple build instances and feeds the value of the path that triggered the build into the build definition and so telling the build instance which .sln file to build?
I hope that makes sense!
You can do like below
E.g,
MicroserviceAUpdated
= "False",MicroserviceBUpdated
= "False" etc.,Get the changeset/commit in the build to check which files are changed.
MicroserviceAUpdated
variable to "true" if only any files are changed underSubFolderA
.MicroserviceBUpdated
variable to "true" if only anyfiles are changed under
SubFolderA
.So on....
For MicroserviceA build Task
"Custom conditions":
and(succeeded(), eq(variables['MicroserviceAUpdated'], 'True'))
For MicroserviceB build Task
"Custom conditions":
and(succeeded(), eq(variables['MicroserviceBUpdated'], 'True'))
So on...
This way MicoserviceTask will be skipped if the value of the variable is
False
For Step 2
On the Triggers tab, there is an option to specify the path to the project you want to build. When that path is specified, only commits which contain modifications that match the include/exclude rules will trigger a build.
In my case this is a much better solution than the PowerShell script which still triggered builds and releases on all the projects spamming our Slack and filling with rubbish our project's history.
Jayendran answer is very excellent! Here's a more PowerShell-y way to do step 2: