0

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:

  1. Creates the NuGet package only when there are changes in Project N and its dependencies
  2. 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.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
ccoutinho
  • 3,308
  • 5
  • 39
  • 47
  • 1
    You can't control the order in which separate pipelines are queued. You can, however, control the order in which **jobs** are triggered within a pipeline. Thus, you should do this as a multi-job pipeline with some conditionals to ensure that the appropriate jobs only run if necessary. – Daniel Mann Apr 08 '20 at 15:21
  • @DanielMann The NuGet package creation job should only run when the files within a specific project (out of many in the solution) have been changed. Is there a way for me to specify such condition in a job? – ccoutinho Apr 13 '20 at 14:10
  • Hi rsy, Did you get a chance to implement the solution that *PaulVrugt* suggested? Were you able to resolve? – PatrickLu-MSFT Apr 16 '20 at 01:59
  • 1
    Hi! Yes I did, but it does not comply yet with the requirements I wanted to meet. I will later give a try to the suggestion he gave me in the comments, and use a powershell script to check if there has been changes in the package before running the task. That is why I decided to keep this question open, and not accept his answer – ccoutinho Apr 16 '20 at 08:33

1 Answers1

1

I don't think there is any way to do what you want. If the order of the two jobs is important, you should put them in the same pipeline. Within a pipeline, you can create dependencies between jobs.

see https://learn.microsoft.com/en-us/azure/devops/pipelines/process/stages?view=azure-devops&tabs=yaml

However, this would mean that both jobs would ALWAYS run. This might not be an issue, because in the nuget push task, there is an option to ignore duplicate versions (in case project N was not changed, it still has the same version):

enter image description here

So in summary:

  • Create a single pipeline with 2 jobs
  • make the "main pipeline" job dependant on the "Project N" job
  • in the "Project N" pipeline, make sure to enable the "allow duplcates to be skipped" option
PaulVrugt
  • 1,682
  • 2
  • 17
  • 40
  • I think your suggestion is the best I can find for my problem. I am still testing, but I have some constraints that make me consider sticking to my current setup: 1) I use yaml files to describe the pipeline, not the UI. And I am not succeeding in setting up the NuGet push to "allow duplicates to be skipped". 2) There are many tasks related with this NuGet package creation, for example, running tests. Even if I manage to configure the push to "allow duplicates to be skipped", on every build these tasks will all be executed, and only the push will be skipped. – ccoutinho Apr 13 '20 at 14:08
  • The property you are looking for is called "AllowPackageConflicts", which you need to set to true. About the extra tasks, is this really an issue if these tasks run? I don't really see a way to work around this, except by writing a powershell script at the beginning of the job to check whether or not the current version of the Nuget package already exists. – PaulVrugt Apr 13 '20 at 16:34
  • The issue is the unnecessary time it adds to the builds. Builds are already taking too long, and also because it might deplete the free monthly build minutes faster – ccoutinho Apr 13 '20 at 17:34
  • 1
    You could use a powershell script using find-package (https://learn.microsoft.com/en-us/powershell/module/packagemanagement/find-package?view=powershell-7) to check if the current package version is already in Nuget. If you add this to the beginning of the job, you can make the rest of the tasks conditional according to the result of check – PaulVrugt Apr 13 '20 at 17:48