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.
Related
I have a deleted artifact in a feed (and no more visible in the recycle bin, because permently deleted) :
And I can't republish the same artifact, because It seems still present in the feed :
I tried also to create a new feed :
And I tried to publish the same artifact in the new feed, but I have the following error message :
Could you tell me how can I republish the artifact please?
Regards,
Yannick
Azure DevOps : not possible to publish again a deleted artifact
This is the default behavior.
I understand how frustrating this is for you. But this is what Azure Artifacts deliberately designed to ensure the correctness of the build results.
Check the document: Understand immutability of packages.
Once you publish a particular version of a package to a feed, that
version number is permanently reserved. You cannot upload a newer
revision package with that same version number, or delete it and
upload a new package at the same version.
You could check my previous thread for the reason for this design.
To resolve this issue, you could try to publish the artifact with another version. If you do not want to change the version, you need to upload this artifact to another feed, and add this feed as package source.
I have a GitHub worflow which builds and deploys a snapshot version of a library as a GitHub package, e.g., mycompany.mytool.1.0.0-SNAPSHOT.jar. Whenever I make a new build and deploy, a new asset is created, like, e.g., mycompany.mytool.1.0.0-20210723.145233-1.jar instead which is then somehow associated with the SNAPSHOT tag. This all seems to work and I can access mycompany.mytool.1.0.0-SNAPSHOT.jar without problem.
My question now is, how can I get rid of all these older versions of this jar? Actually I just want to keep the latest version. I can delete them manually via the web-interface but that is a more than awkward task. I would somehow like to automate this too.
This is not possible as of this writing. GitHub staff member Jamie Cansdale wrote this in their community forum:
SNAPSHOT versions are exposed as artifacts inside a regular versions. There isn’t an API for cleaning up artifacts, only whole versions.
(source)
Which means that a single SNAPSHOT version (like 1.0.0-SNAPSHOT) will accumulate all builds you make, and all artifacts will show up on the Assets list to the right of the web page.
The only practical solution I can think of, is that you delete the whole version from a script, before publishing each build's artifacts. Then you'd have the effect of having a single set of artifacts stored as part of the 1.0.0-SNAPSHOT version name.
However this solution is not ideal: public package versions cannot be deleted if they are popular enough (probably to avoid squatting attacks):
If the package is public and the package version has more than 5,000 downloads, you cannot delete the package version. In this scenario, contact GitHub support for further assistance.
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
We changed our maven private repository Nexus to Azure Artifacts.
And when we upload a private maven dependency with a some version, it told us below info:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project HmapBasic: Failed to deploy artifacts:
Could not transfer artifact com.hand:HmapBasic:pom:3.0.3-RELEASE
from/to dev-azure-com-kohlerdevops-konnect-unified
(https://pkgs.dev.azure.com/KohlerDevOps/_packaging/Konnect-Unified/maven/v1/):
Failed to transfer file:
https://pkgs.dev.azure.com/KohlerDevOps/_packaging/Konnect-Unified/maven/v1/com/hand/HmapBasic/3.0.3-RELEASE/HmapBasic-3.0.3-RELEASE.pom.
Return code is: 409
I searched the code 409 error. It means we have already uploaded the dependency with this version and we can't upload this again.
We want to use the new dependency cover the old one without changing version(because if we change the version, all of our projects need to change pom.xml)
how can we do that in Azure Artifacts?
How to update a maven dependency with a same version number in Azure Artifacts
I am afraid you have to change the pom.xml, I understand how frustrating this is for you. But this is what Azure Artifacts deliberately designed to ensure the correctness of the build results.
Check the document: Understand immutability of packages.
Once you publish a particular version of a package to a feed, that
version number is permanently reserved. You cannot upload a newer
revision package with that same version number, or delete it and
upload a new package at the same version.
The reason for this design:
That because many package clients, including NuGet, keep a local cache
of packages on your machine. Once a client has cached a particular
package#version, it will return that copy on future install/restore
requests. If, on the server, you replace package#version (rev 1) with
a new package#version (rev 2), the client is unable to tell the
difference. the client still use the old version in cache. This can lead to indeterminate build results from
different machines.
So we could not overwrite all packages that have already been
uploaded, even we could not delete them and re-uploaded. To resolve
this issue, the only way is that upload the packages with a new
version.
Check my another thread for some more info.
Hope this helps.
I just made a test on Azure DevOps and if you use the "SNAPSHOT" suffix it will overwrite the previous package/artifact. For instance 2.0.0-SNAPSHOT.
I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.