Replies: 1 comment
-
I know this is old, but I'm getting into Nuke Build as an Azure DevOps engineer. As you're probably aware by now, Azure DevOps now allows you to define your entire pipeline as a single YAML file. Effectively, all pipelines are just "build" pipelines now. Anything you could do with Build -> Release pipelines you can do with YAML pipelines, although the implementation might take a bit of redesigning. When it comes to Nuke Build, this means you can run your whole pipeline in Nuke by simply running your Deploy target; or you can run the individual targets separately with individual Nuke runs one after another as steps within a single job. If your deployment process absolutely requires completely separate build and deploy processes, then you could use Nuke's global tool feature, build your Nuke project as a runnable dotnet tool, publish it to a private NuGet repository, and then restore it during your deployment pipeline along with the pipeline artifacts from an earlier build pipeline run. Note I haven't tried this myself yet, but it should be possible according to the documentation. |
Beta Was this translation helpful? Give feedback.
-
I've got a bit of an issue with how DevOps splits pipelines and releases and subsequently deploying code using nuke. Locally I've got it set up so that you can just
./build.ps1 deploy
and it'll deploy code to the configured environment automatically. This works great when you have the project files available and you're in the repo root.This falls over however when trying to move this process into Azure DevOps. Because you can only pull artifacts in a release, any nuke commands fail because the solution isn't present.
Just looking to see what other people have done here or have any solutions, only immediate one is to produce another artifact with the source root available. Alternatively, pull the token and then pull the repo again, but these seem more hackish.
Beta Was this translation helpful? Give feedback.
All reactions