We have a custom feed in Azure DevOps Server for NuGet packages. When uploading the Microsoft.AspNetCore.Authentication.Core 2.2.0 package something went wrong and now we have a bad package in our feed.
According to this question, asked and answered several years ago, it is not possible to replace the package, only increment the number and push a new version.
What are supposed to do when we don't control the version number of the package and need to replace the bad upload?
Right now, the only option we can see is to create a new feed and reupload everything from the old feed.
What are supposed to do when we don't control the version number of the package and need to replace the bad upload?
As I mentioned in that thread, in order to avoid contamination of the package source, MS strictly controls the package version, does not allow upload a newer revision package with that same version number, or delete it and upload a new package at the same version.
So, if we don't control the version number of the package and need to replace the bad upload, we have to create a new feed to save this specify package.
BTW, if you do not want to reupload everything from the old feed, you could try following workaround:
Upload the package Microsoft.AspNetCore.Authentication.Core 2.2.0
to the new feed.
Delete the damaged package from the old feed.
Add the new feed as upstream source for the old feed.
Now, we could restore the nuget package from the old feed.
Note: Do not reverse the order of step 1 and 3, otherwise you could upload the package due to the 409 conflict error.
Related
So, I've been working on an azure pipeline that is supposed to download a NuGet package and then upload it to a ProGet feet. But it should only upload the package if it doesn't yet exist on the feed to avoid redundancy. (If the package already exists on the feed, but the version is different, it should still be uploaded). Is there a way to check if a package already exists on a ProGet feed using nuget.exe or some other kind of NuGet tool?
You can use one of the several options here.
The first one is to use nuget.exe, in particular, its list command. The following command will list all versions of the package available on the feed:
nuget list <PackageName> -Source <ProgetFeedURL> -AllVersions
where <PackageName> is obviously the [part of the] package name, and <ProgetFeedURL> is the feed URL. The output is a list of packages along with their versions you can easily parse to find out whether the version in question is already on the feed.
The other approach could be to form a download URL for a package in ProGet and send a simple GET request to that URL. The URL is generally formed like this (note that your version of ProGet might form a different URL. You can verify that if you hover a mouse over the Download button in the browser):
http(s)://<ProGetServer>/nuget/<ProGetFeed>/package/<PackageName>/<PackageVersion>
In case this GET request results in 404, you can be sure there's no such version of that package on the feed.
I suppose there must be some REST API of Proget to verify a similar stuff, but I haven't worked with that.
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 have a newly created Feed in Azure DevOps where I'm hosting my Nuget packages. I uploaded a bunch, but when I tried to download My.Package.1.0.4 it isn't listed in the feed; neither in VS nor on the web portal. My.Package.1.0.5-beta-2 is there, but even in the version list 1.0.4 is not shown.
I figured it just didn't get uploaded - so tried again; when I do, I get the error Response status code does not indicate success: 409 (Conflict - The feed already contains 'My.Package 1.0.4'.
My question is: where is it hiding? It doesn't show up in the feed anywhere, but it apparently uploaded successfully. What do I do now?
It could happen when package was deleted:
When 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 can check it here:
I want to publish a new version of a NuGet package, but I want it automatically in an Unlisted status. When I manually upload the .nupkg file to nuget.org, in the preview there is an option to unlist the package from search results:
Is there a way to do that with nuget.exe or dotnet nuget?
I was able to use PUSH + DELETE commands to achieve this, but I'm not sure this is the same as the above manual action.
For instance, one of the concerns is what happens to the package's RSS (atom.xml)?
Does it first get a new entry which is then deleted later on? In which case, is it possible that someone would still get notified about this release?
Last, I am aware of private NuGet feeds, but regardless, I would still like to use just the main NuGet, for convenience's sake.
Well, this is my first Nuget package I publish, it's as simple as any first..
I've published it through this command line:
nuget push PKG.1.0.0.0.nupkg 0000000-000-0000-0000-0000000000 -Source https://www.nuget.org/api/v2/package
but I don't know how to update it, you know how difficult it is to google "update nuget package"!
Changing the version number is all what I needed,
but changing the package name will likely publish new package
Another way, if you do not want to use the CLI and push your package, is to go to nuget and in the upload section, upload your package with a higher version number. It will pick up the package ID so you wont be publishing a whole new package. That will update your package on your behalf after nuget validates the uploaded package.