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!
Continuous deployment triggers help you start classic releases after a classic build or YAML pipeline completes. Scheduled release triggers allow you to run a release pipeline according to a schedule. Pull request release triggers are used to deploy a pull request directly using classic releases.
Azure Pipelines must be granted access to your repositories to trigger their builds, and fetch their code during builds.
Select trigger: Set the trigger that will start the deployment to this stage automatically. Select "Release" to deploy to the stage every time a new release is created. Use the "Stage" option to deploy after deployments to selected stages are successful. To allow only manual deployments, select "Manual".
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 under SubFolderA
.MicroserviceBUpdated
variable to "true" if only anySubFolderA
.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
$files=$(git diff HEAD HEAD~ --name-only) $temp=$files -split ' ' $count=$temp.Length echo "Total changed $count files" For ($i=0; $i -lt $temp.Length; $i++) { $name=$temp[$i] echo "this is $name file" if ($name -like "SubFolderA/*") { Write-Host "##vso[task.setvariable variable=MicroserviceAUpdated]True" } }
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With