I've been setting up a build pipeline which included a Nuget Restore task.
I followed the instructions at https://learn.microsoft.com/en-us/azure/devops/pipelines/packages/nuget-restore?view=azure-devops but the pipeline stalled for long enough for me to cancel it.
Looking at a build pipeline already in place for another project, I noticed version 0 of the Nuget Restore task was being used whereas the one I was trying to figure was version 2.
Having altered my build pipeline to use version 0 of the task, the build pipeline now completes in a reasonable time.
The main question I have regards the fact that I struggle find documentation on the Devops build tasks and when I do there is little explanation of what all the fields and options are used for when to use the different versions.
Can anyone recommend a resource for that?
Failing that can anyone offer an insight as to what is the difference between each version of the Nuget Restore task and when to use each?
Thanks
From your description, I think the 'version' means this, right?
If so, when you change the command from 2 to 0, the task already changed in fact.
You can see the task name here:
2.*:
NuGetCommand#2
Details link:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget?view=azure-devops
0.*:
NuGetInstaller#0
Details link:
https://learn.microsoft.com/en-gb/previous-versions/azure/devops/pipelines/tasks/package/prev-versions/nuget-installer-0?view=tfs-2017
For the index of most DevOps built-in tasks:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/?view=azure-devops
For those backward compatible tasks：
https://learn.microsoft.com/en-gb/previous-versions/azure/devops/pipelines/tasks/?view=tfs-2017
The above resources should be enough.
Related
I am new to Azure DevOps and trying to create my first Azure pipeline. I have a ASP.NET MVC project and there are a few NuGet packages that need to be restored before the MSBuild step.
Unfortunately, the NuGet restore is failing with the following error:
The pipeline is not valid. Job Job_1: Step 'NuGetCommand' references
task 'NuGetCommand' at version '2.194.0' contains an execution handler
that relies on NodeJS version '6' which is restricted by your
administrator.
NodeJS 6 came disabled out of the box so we are not going to enable it.
My Questions:
Is there an alternative to NuGet restore that does not use NodeJS?
Is there a way to update the NodeJS6 to a higher version?
update 23-Nov-2021
I have found a work around for the time being. I am using a custom PowerShell script to restore NuGet Packages and build Visual Studio project
$msBuildExe = 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe'
Write-Host "Restoring NuGet packages" -foregroundcolor green
& "$($msBuildExe)" "$($path)" /p:Configuration=Release /p:platform=x86 /t:restore
Note: $path here is the path to my .csproj file
Apparently, other people are also getting the same issue and it is just a matter of time that the task is updated by the OpenSource community.
Here are some similar issues being faced in other tasks as well:
https://github.com/microsoft/azure-pipelines-tasks/issues/15526
https://github.com/microsoft/azure-pipelines-tasks/issues/15511
https://github.com/microsoft/azure-pipelines-tasks/issues/15516
https://github.com/microsoft/azure-pipelines-tasks/issues/15525
It's AzureDevOps' NuGetCommand task that uses NodeJS, not NuGet itself. Therefore, you can find a way to restore without using Azure DevOps' NuGetCommand task.
Idea 1: use DotnetCoreCli task instead. However, this probably won't work for you since you said your project is ASP.NET MVC, rather than ASP.NET Core. Also, it also appears to need NodeJS to run.
Idea 2: Use MSBuild restore. You can test on your local machine whether or not this works by clearing your global packages folder, or temporarily configuring NuGet to use a different path, and then running msbuild -t:restore My.sln from a Developer PowerShell For Visual Studio prompt. If your project uses packages.config, rather than PackageReference, you'll need to also pass -p:RestorePackagesConfig=true (although maybe this is currently broken). I'm not an expert on Azure Pipelines tasks, so I don't know what it means that this task defines both PowerShell and Node execution entry points, but maybe it means it will work even if your CI agent doesn't allow NodeJS.
Idea 3: Don't use any of the built-in tasks, just use - script: or - task: PowerShell#2, but even that is a little questionable whether it'll work since even the powershell task defines a Node execution entry point. I'm guessing it will work, but I don't have access to a CI agent where NodeJS is forbidden, so I couldn't test even if I wanted to. Anyway, if this works, then you can run MSBuild yourself (but it might also be your responsibility to find msbuild.exe if it's not on the path). Or you can download nuget.exe yourself and execute it in your script. The point is, if you can get Azure Pipeline's script task working, you can run any script and do everything you need yourself.
Idea 4: Use Microsoft Hosted agents. They have documented all the software they pre-install on the machines, which includes Node JS. Downside is that once you exceed the free quota it costs money, and I've worked for companies where it's easier to get money to buy hardware once-off, and pretend that maintenance of the server is free, even though it reduces team productivity, rather than pay for a monthly service. So, I'll totally understand if this is not an option for you.
Idea 5: Talk to whoever maintains your CI agents and convince them to allow & install NodeJS. It's clearly a fundamental part of Azure Pipelines. The tasks are open source on github, and you can see that pretty much all of them use NodeJS to orchestrate whatever work it does. Frankly, I thought the agent software itself was a NodeJS application, so I'm surprised that it runs without NodeJS.
So, recently I set about migrating our Azure Devops Classic Release pipeline to a YAML based one.
What I'm struggling to reproduce is the ability you have with a Classic Release pipeline to select a specific artefact from an associated build pipeline using a dropdown list.
The only way I've found to allow a user to specify a specific artefact is via a parameter, but the definition of dropdown lists is only possible if you know all of the values that will be in the list.
This link is the closest thing I've found that resolves the issue, but even this doesn't allow the specification of a dropdown: https://www.huuhka.net/runtime-artifact-selection-in-azure-pipelines-yaml/
Anyone know how to do this, or even if it is possible?
Ok, so I didn't quite answer the question I posed, but I found an answer that solves the issue I have.
The problem I had is that I want a user to be able to select a specific build at release time.
This is poorly documented and it was a surprise when I saw it working.
In your release pipeline specify a resource:
resources:
pipelines:
- pipeline: YourBuildPipelineReference
source: "Your Build Pipeline Name"
Now when you come to run your pipeline you see the following:
Click Resources and you are now taken to list where you can select a specific build.
Didn't see this before, but I figure lots of people will need this.
We are using Azure Devops with Octopus deploy.
I have integrated the release steps, and release creation as well as release to first environment (Development in my case) is happening without any issue.
Issue is with subsequent releases.
Release fails in Semantic Versioning check of release name.
'1.2.1023.0508-09' is not a valid version string
at Octopus.Client.Model.SemanticVersion.Parse(String value, Boolean
preserveMissingComponents)
In the first stage, I am creating Octopus release, and deploying to Development environment in the same task (using Create Octopus Release task in Azure devops)
create-release "--project=<projectName>" "--releaseNumber=1.2.1023.0508-09" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"
This step is successful.
In the next stage, I have tried 2 variations,
Promote Release
promote-release "--project=projectName" "--server=serverName"
"--apiKey=***" "--from=Development" "--to=envName"
Deploy Release
deploy-release "--project=projectName" "--releaseNumber=latest"
"--server=serverName" "--apiKey=***" "--deployTo=envName"
Both of them giving same error, saying release name is not a valid version string.
My confusion is, if the name is incorrect, even the first deployment should fail.
If it's correct and allowed, then subsequent stage release should also succeed.
If any one has faced such a issue before, or can add in some pointers to resolve this issue, it will be very helpful.
This sounds like a bug but I'd need more time to reproduce and verify. Can you share what version of Octopus and the Octopus Extension you are using?
My best suggestion to get going with this is to base the release number off of your Azure DevOps build number and use that variable to control what version is getting deployed. Using the 'latest' version could backfire if you have other releases created in between your stages.
If you can set your Azure DevOps build number to be in the same format that you want your Octopus release number (1.2.1023.0508-09), you can use the following commands to build and promote a release.
create-release "--project=<projectName>" "--releaseNumber=$(Build.BuildNumber)" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"
deploy-release "--project=projectName" "--releaseNumber=$(Build.BuildNumber)" "--server=serverName" "--apiKey=***" "--deployTo=envName"
This will make sure that you are promoting the same release that was created in the pipeline.
Just in case if someone came here looking for solution, below are the steps I took to solve the problem,
For first stage (dev in my case), create a new release. If you have multiple tenants, add them. Do not forget to add Package Version. This is especially needed when you have multiple versions of artifacts getting created. I faced hard time resolving this. if you do not add PackageVersion, latest available artifact is picked.
For further stages, DO NOT promote release. Instead, deploy release. This way, you can pass the same release number as configured in first stage. In my case, I kept the stage name same as my environment name. So I was able to use variable for env as well. I copied this stage for 4 different environments.
So I'm currently trying to proceed through the release pipeline portion of an Azure DevOps Fundamentals for beginners course on Udemy, and the goal is to deploy the code for a small webapp game called "Flatris" for the purpose of showing how Azure works.
I've been following along with all the steps as per the course, but when I run the release pipeline build, it consistently fails with the message:
"Error: No package found with specified pattern: D:\a\r1\a***.zipCheck if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job."
So far, I've double checked the function of the Web App resource provided through Azure, it's showing traffic when I try and run the pipelines, so it's not the problem(i think), I've double checked the repositories, and they seem to be functioning well(i think), I'm unsure about the artifacts and whether that may be the source of the problem, but theres not enough specificity in the error logs for me to accurately isolate where the problem is.
I don't know if anyone else has managed to get pat this problem, or if it's unique to me with something I'm doing, but any help would be greatly appreciated.
Error: No package found with specified pattern: D:\a\r1\a***.zip
Check if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job."
When we use release pipeline for our application, we have to specify the artifacts that make up the application. And the artifact is a deployable component of your application. It is typically produced through a Continuous Integration or a build pipeline. Azure Pipelines releases can deploy artifacts that are produced by a wide range of artifact sources such as Azure Pipelines build, Jenkins, or Team City.
According to the error message, it seems you are using the build pipeline as artifact resource in the release pipeline.
To resolve this issue, we need make sure we have use the Publish build artifacts task to publish the artifacts to the Azure Pipelines in the build pipeline.
Then select the above build pipeline when we select the artifact source type:
In this case, Azure release pipeline will download the artifact automatically when we execute the release pipeline, the artifact will be save in the default folder D:\a\r1\a. That will resolve your issue.
I have a VSTS project and I'm setting up CI/CD at the moment. All fine, but I seem to have 2 options for the publishing step:
Option 1: it's a task as part of the CI Build, e.g. see build step 3 here:
https://medium.com/#flu.lund/setting-up-a-ci-pipeline-for-deploying-your-angular-application-to-azure-using-visual-studio-team-f686c8f190cf
Option 2: The build phase produces artifacts, and as part of a separate release phase these artifacts are published, see here:
https://learn.microsoft.com/en-us/vsts/build-release/actions/ci-cd-part-1?view=vsts
Both options seem well supported in the MS documentation, is one of these options better than the other? Or is it a case of pros & cons for each and it depends on circumstances, etc?
Thanks!
You should definitely use "Option 2". Your build should not make changes in your environments whatsoever, that is strictly what a "release" is. That link you have under "Option 1" is the wrong way to do it, a build should be just that, compiling code and making artifacts, not actually deploying code.
When you mesh build/releases together, you make it very difficult to debug build issues. Since your code is always being released, you really have to disable the "deploy" step to get any idea of what was built before you deployed.
Also, the nice thing about creating an artifact is you have a deployable package, and if in the future you need to rollback to a previous working version, you have that ready to go. Using the "build only" strategy, you'd have to revert your code or make unnecessary backups to achieve this.
I think you'll find any new Microsoft documentation pointing you toward this approach, and VSTS is completely set up like this. Even the "Configure Continuous Delivery in Azure..." feature in Visual Studio 2017 will create a build and a release.
Almost all build tasks are the same as release tasks, so you can deploy the app after building the project in build process.
Also there are many differences between release and build, for example, many environments, deployment group phase in release.
So which way is better is per to your detail requirement, for example, if build > deploy > other process is simple, you can do it just in build.
Regarding Publish artifact task, it is used to publish the files to VSTS server or other place (e.g. shared folder), which can be used in release as Artifact (Click Add artifact > Build in release definition), you also can download them for troubleshooting, for example, if you are using Hosted Agent that you can’t access, but you want to get some files (e.g. build result), you can add publish artifact task to publish to VSTS server, then download them (Open build result > Artifacts)