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
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 am new to Azure Devops. I want to use Azure artifact to publish my build artifacts there so that we can use them as a Maven dependency. The issue I am facing is when I deploy a newer version of my artifact, it overrides the previous version. This can lead to issues for the user of my artifacts.
Is there any specific settings using which I can change this behaviour?
According to your description you are using the Azure Artifact feed, right?
If it is, then the old version of packages will not be overwritten by the new versions. By default we can see the latest version of packages in the feed home page. However we can click the specific package, then switch to the Versions tab to check the old versions of that package.
Then you can reference the specific version of the packages in your project.
My CI build tool (Bamboo) has been set up to build and deploy my component to NuGet with a -buildxx suffix to indicate it is a pre-release version.
Once we have completed QA, I want this pre-release package to now become the stable version and essentially remove the -Suffix. How can I go about doing this from the NuGet Command Line as I want to automate it via our CI tool in a deployment plan.
I am currently designing an automated build environment for releasing of various NuGet packages for my organisation.
As it stands, I want to be able to produce various "levels" of stability for NuGet releases, starting with triggered (i.e: builds made by POST hooks on the develop branch) as a replacement for nightlies, followed by source promoted to alpha/beta, RC then "stable" packages.
NuGet has stable and prerelease options for package retrieval, however, prerelease cannot distinguish between different prerelease stages, such as 1.2.3-beta123 and 1.2.3-alpha123 etc.
Is there any way to allow package consumers to select the "lowest" level of stability they would like to subscribe to? AFAIK, the only solution is to create different feeds that are selectively published to during the build process, then work from there. Refer to something like the Xamarin Studio Update setting below;
This is not something that is built in to NuGet. NuGet separates NuGet packages by their source.
Some teams publish nightly builds to MyGet and only publish official release NuGet package builds to nuget.org but that is just a split of pre-release from release which you could do on one package source.
We are building packages for multiple deployment environments using TeamCity server and OctoPack. The problem is that tentacle agent chooses the latest by number version of the package, so it's the same (latest) package that is deployed on all environments. Here's the summary of our setup:
Environments DEV and STAGE;
Deployment to DEV is triggered from Git "dev" branch;
Deployment to STAGE is triggered from Git "stage" branch;
OctoPack is configured to generate packages MyProduct.1.0.0.dev-%build_counter% for DEV build configuration;
OctoPack is configured to generated packages MyProduct.1.0.0.%build_counter% for STAGE build configuration;
TeamCity is configured to expose OctoPack artefacts (NuGet packages) via its NuGet feed;
Octopus project is configured to deploy packages with NuGet Id MyProduct from TeamCity NuGet feed.
So what happens is that since DEV builds are run more frequently, they have larger %build_counter%, and STAGE doesn't get a chance to get a deployment of its own packages - Octopus tentacle preferes packages with 1.0.0.dev-* suffix.
This must be fairly common scenario, but I haven't found a simple way to solve it.
There are some parts that are not documented here: https://github.com/OctopusDeploy/Octopus-Tools. But if you look at https://github.com/OctopusDeploy/Octopus-Tools/blob/master/source/OctopusTools/Commands/CreateReleaseCommand.cs it is possible to figure out what you can do.
I think the tools is backward compatible, but not 100 % sure about that.
When you are using the octo tools, which I expect that you use, you can set the version (also called releasenumber now) option to specify the release number. If you doesn't specify anything else it will take the latest package so what you want to do is set the packageversion (also called defaultpackageversion now) that should be used for the release.
I think that should do it. If it doesn't, what are you using to create the release?
Example of what we are using from our TeamCity when using octo tools which we have added to the environment path on the build agents:
create-release --server=%conf.OctoServerApi% --project=%conf.OctoProject% --version=%env.OctopusPackageVersion% --deployto=%conf.OctoDeployEnv% --packageversion=%env.OctoPackPackageVersion% --apiKey=%conf.OctoApiKey% --waitfordeployment %conf.OctoExtraParams%
UPDATE:
The documentation for 2.0 is much better: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596
Inspired by Tomas Jansson's answer, simply adding the following to Additional command line arguments in the OctopusDeploy: Create release build step (TeamCity v9) worked for me:
--packageversion=%build.number%