I am using Azure devOps to build and deploy my application, and within that application I have a project that is being used by other related applications (let's call it project N). Thus I decided to deploy this project as a NuGet package, and consume it during the build.
Project N is likely to change often, thus I am having some trouble in defining a reliable setup that:
- Creates the NuGet package only when there are changes in Project N and its dependencies
- Guarantees that, if the NuGet package is to be created, as per 1), the pipeline does that before anything else
The way I have setup this so far, is to have two different pipelines, one that creates the NuGet package and deploys it (NuGet Pipeline), and another one that consumes that NuGet package and then builds and deploys the application (Main Pipeline).
The problem is, when changes happen both in files related with Project N, and in some of the remaining files of the solution, I don't know how to make a rule that says "Run NuGet Pipeline before the Main Pipeline", so for the moment I have to trust in luck for that to happen, and if not, I would have to manually trigger the Main Pipeline after the two build are finished. Because I want to be sure that the new changes introduced in the Project N do not break the Solution.
Is there an elegant way to do that? I could setup a trigger that, whenever the Pipeline NuGet finishes it would trigger the Main pipeline, but by doing it that way I would trigger the Main Pipeline twice whenever changes would be made to the Project N and to the rest of the solution.