I am setting up a DevOps release pipeline that is triggered off a build pipeline.
The build pipeline uses the Nuget Pack to create a nupkg file and publishes it as an Artifact.
The release pipeline is triggered and Nuget Push is used to deploy to the DevOps feed.
I have found the “Promote package to Release View” task, but how do I get the Package Version to provide in the step?
I should note that, in the build pipeline, the Nuget pack step uses the build number for the version.
According to your description, the build pipeline uses Nuget pack with the build number for the version. So, you just need to enable the CD (Continuous deployment trigger) for your release pipeline. Then use the predefined variable Build.BuildNumber in the “Promote package to Release View” task.
Select the package that you want to promote. Multiple packages may be supplied separated with a comma or semicolon. Note you may use either the name of the package or its GUID.
Related
Our build environment is VSTS pipeline and our development environment is visual studio.
We are using dev branches (or feature branches) and we have a main branch (master branch).
As piece of code are getting stable and don't need much debug, We are now willing to split our projects into nuget packages.
As long as we are in dev or feature branch, we want to generate and use the -alpha nuget package to test and use the latest code.
But as soon as we are doing a pull request to the master branch, we want to use the stable nuget package.
Of course, without having to manually go to the nuget package manager and update every nuget package before committing;
Said differently, every project in a dev branch should automatically build with the -alpha version of each nuget package and the build of the master branch should be with the stable version of the package.
How can we create a vsts pipeline to achieve this
conditionnally select nuget package during build
You could add a task (powershell or batch) to modify the nuget.config or the project file to update the package version with condition.
steps:
- powershell: |
# Write your PowerShell commands here.
update the package version in the nuget.config or project file.
displayName: 'Update package version'
condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
You create two (build) pipelines:
Dev / Feature you name it -> gets triggered by your feature/* branches and publishes your -aplpha nuget package
Stable / Prod -> gets triggered by pull requests into the main branch and publishes the stable nuget package
I personally don't have much experience with YAML, yet, but in the classic pipeline editor you can easily add tasks. Each pipeline should roughly be looking like this:
Some more details:
Missing on the screen shot is the important trigger part. You can also edit that in the classic pipeline editor in the "trigger" tab. There you choose your feature branch setting (e.g. feature/*) and exclude the master on the feature pipeline.
Converting all to YAML should be straight forward via the "View YAML" feature in the classic web editor.
Depending on your private setup you might need extra steps like NuGet auth if you use a private NuGet server etc..
I have a DACPAC deployment task which is failing, because for some reason the value of the $(Build.ArtifactStagingDirectory) pipeline variable is changing between the build pipeline and the release pipeline. In the build pipeline, the variable is set to C:\agent\_work\2\a, but in the release pipeline it's C:\agent\_work\r2\a. This is causing the release pipeline to fail when it tries to deploy the DACPAC artifact, because the folder it's looking in is empty; the folder where the artifact actually is is ignored. How do I make these variables consistent between the build and release pipelines so that the artifact is retrieved from the same folder it's generated in? These variables appear to be built in, so I don't see any way to change them. I could always hardcode a path, but that seems a bit kludgy...
In releases you have System.ArtifactsDirectory which is
The directory to which artifacts are downloaded during deployment of a release. The directory is cleared before every deployment if it requires artifacts to be downloaded to the agent. Same as Agent.ReleaseDirectory and System.DefaultWorkingDirectory.
Example: C:\agent_work\r1\a
and in pipelines/builds Build.ArtifactStagingDirectory
The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: c:\agent_work\1\a
A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks.
Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself.
See Artifacts in Azure Pipelines.
This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
This is in line with your experience. And you cannot change it, as they are predefined. But can you clarify why this is a problem for you?
In the release pipeline, you can't directly access the files in the build pipeline, not only because the working directory is different, but also because they do not use the same agent. You need to download the artifacts first, and then use them in the release pipeline.
You can use the following ways to download artifacts:
Use the Download Build Artifacts task.
Go to the edit release pipeline page -> Select Add artifact -> Select Build -> Fill in the information related to the build pipeline (Notice the value of Source alias)-> Add it. You will find your artifacts are downloaded in $(System.ArtifactsDirectory)/${Source alias}
For more information about consuming artifacts in release pipelines, you can click this document.
Oh, I think I figured it out. Each release pipeline stage has an option called "Artifact download" which lets you specify which artifacts out of all those linked in the pipeline are actually used by that stage. I needed to check the appropriate checkboxes there in order to use the artifacts in the stage's tasks.
How to use azure pipleline for creating nugetpackes and deploying to orchestrator?
The generation of the package is running with the following package: https://marketplace.visualstudio.com/items?itemName=uipath.vsts-uipath-package
In the case this is the right way what's the solution to upload them to orchestrator?
Possibility 1: Create nuget feed in azure (one feed for TEST and one
for PROD)
Possibility 2: Deploy packages to orchestrator directly
Though I am not one of the developer for UiPath, as I know, this extension hasn't integrated with our Azure Devops feed. So, your first possibility solution should not suitable in VSTS.
To achieve what you want, I suggest you pack and deploy the packages by using the UiPath Package task directly.
Create the package in build pipeline:
Create a build pipeline, add and configure the UiPath Package task by following the description here. For create the package, please choose Pack as Package action value:
Note: Please keep the default value of Output folder as $(Build.ArtifactStagingDirectory). It is the path which used to store the artifact, then got by the release pipeline.
Deploy the package to orchestrator in Release pipeline:
Create a Release pipeline, choose the build you executed previously as the source.
Add the same task into the stage, but here please choose Deploy as Package action value:
Then configure your Orchestrator info and the identity Authentication details.
I created a private NuGet feed in Azure DevOps following this guide and created a build pipeline with dotnet pack and dotnet nuget push steps. After running the build a few times, the new versions are displayed under Artifacts >> MyFeed >> Versions. I promoted some of the versions by hand to #Release.
Here's the view in DevOps:
But when I connect to the feed in Visual Studio, I only see version 1.0.0 as stable release, but all later versions (which are published via my build pipeline), are only shown if I check the "include pre-release" option. Here's a screenshot:
My questions are:
1 - how can I manually promote a version to stable?
2 - how can I promote a version to stable via a build or release pipeline?
Azure DevOps - Private NuGet feed doesn't update stable release
Just like zivkan said "anything after a - character signals pre-release information.". You can check the nuget document Package versioning for some details.
1 - how can I manually promote a version to stable?
You can download that package from your nuget feed, then change the package version to stable, then re-push it to the feed.
2 - how can I promote a version to stable via a build or release pipeline?
To promote a version to stable via a build or release, you could change the build number. When you use dotnet pack task to create the nuget package, there is an option Automatic package versioning:
Update:
So, try to use the option Use the build number option on the Automatic package versioning.
Then, in the Build number format option, you can set it to $(Major).$(Minor).$(Patch)$(Rev:.r):
The value of $(Major), $(Minor), $(Patch) are custom variables in the Variables tab, the value of $(Rev:.r) is the build number.
In this case, the package will be TestSample.1.0.0.5.nupkg.
Hope this helps.
NuGet uses Semantic Versioning 2.0, which says that anything after a - character signals pre-release information. Therefore 1.0.1-CI is prerelease, whereas 1.0.1 would be a release version. If you want build metadata in the version string, you should use the + character, again as defined by SemVer2.
edit: note that SemVer metadata does not contribute to version comparisons, so 1.2.3+CI.1 is considered the SAME version as 1.2.3+CI.2
I have a VSTS release definition that I want to use for publishing nuget packages for multiple artifacts. The artifacts for the different nuget packages are supplied to the release definition from different build definitions. Only artifacts from the build that triggered the release shall be downloaded and published. The pipeline is setup according to the picture below.
That is, when a build triggers a new release, only artifacts from that build should be published in the release. All artifacts from the other build definitions should be ignored since the version number on those nuget packages are not updated and will fail to push.
Can this be accomplished?
Take a look at this link https://learn.microsoft.com/en-us/vsts/release-notes/2018/mar-05-vsts#improve-release-times-by-partially-downloading-artifacts
And then on that same link see Deploy selectively based on the artifact triggering a release
It will basically explain VSTS new features. The first one is to specify what you want to download on a release phase. The second one is to add a custom condition on a phase to define if it should be executed.
So you could create two phases, one for each of your artifacts. Each phase would only download the corresponding artifact and only run if the custom conditional evaluates true, using the new release variable Release.TriggeringArtifact.Alias.
Note that this release variable is only present if the release is continuous deployment.