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.
Related
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.
I want to upload a nuget package to my Github repo's "Packages". This is to say I want to upload a nuget to Github Packages.
However uploading the package with the "dotnet nuget" command automatically sets the description of the package in Github to the description of the csproj file. The problem is that there is no other information about the package, specifically - release notes. That is why, considering my repo already shares the same description, I find the only way to inform users of what was changed in a given version is to write it in the "description" of the package on Github.
Is there a way to specify the description either when uploading the package or after that through use of Github Actions or a CLI or an API or whatever? Because I want it to be done automatically, rather than by hand for every version.
The documentation is silent on this matter.
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.
I have turned on TeamCity's NuGet Server and I want to push in common packages (i.e. from public sources such as NuGet.org) because the build server cannot see outside our company, so restoring packages on the build server from NuGet.org is not possible.
I cannot see how to push these packages on to our TeamCity server. I've seen various answers suggesting to use a package build still or some other means of publishing from within a build, but this is not appropriate for my use case.
If I try to publish from a command line it complains that it cannot find an API key (where do I get that from?) and it won't allow me to enter my credentials (I assume my team city login would be it) as it tells me "Cannot prompt for input in non-interactive mode." (I didn't set that mode and I can't see how to turn that off).
So, how do I push/publish an adhoc package that I obtained elsewhere into team city?
I believe that the nuget functionality provided by TeamCity is an API added on top of TeamCity's builtin artifact functionality.
There are a number of consequences of that:
When a build configuration is executed that produces any .nupkg files that are marked as artifacts, they will be available on the Teamcity nuget feed.
As with all other artifacts nupkgs published in TeamCity are subject to Teamcity's general artifact retention rules.
Access rules for nuget packages are the same as access to the TeamCity projects.
There is however as far as I know no implementation in the Teamcity Nuget API for pushing packages to it. The general practice for storing original or generated packages is to use a stand alone nuget server or service like a normal file share, a Nuget.Core based server, proget or myget.org.
Update:
If you end up with many packages of your own I've heard people reporting that Teamcity becomes quite slow when the clients are resolving the packages.
Update 2:
The last years I've adopted the notion of separating build artifact packages into the two categories library package and deployment package. A separate package repository can be used for both types but a repository such as the one available in for instance Octopus deploy should only be used for deployment packages.
Update 3:
Microsoft have a page for a number of nuget server options.
I have a web public folder which I use when I want to share any file so I was thinking on having my nuget package there. I tried to push it using:
nuget push Me.Utility.1.0.nupkg API_KEY -Source http://www.mywebpage.mx/packages
then it asked me for the credentials but none of the ones I put have worked (the credentials are correct). My web folder is not a nuget feed is just a web shared folder. Is not clear to me if the problem is that it should be a nuget feed (something like myget service) or which is the minimum infrastructure that I need to have since this is only one nuget package. I want to host my package at my own server and also I want my package to appear in the official gallery, so in that case should I set up my own nuget feed?
Could you please explain how this should be done?
MyGet.org supports pushing packages upstream, for instance to NuGet.org. Check out this blogpost to know how to do this: http://blog.myget.org/post/2012/03/01/Introducing-MyGet-package-source-proxy-(beta).aspx
The official gallery meaning nuget.org? With nuget.org you can't choose to host your nupkg on an external site, nuget.org has to host it for you. You might be confusing myget.org and nuget.org concepts.
PS: if you use the argument to override 'source' then you are no longer using the official gallery nuget.org. Hence the question title is confusing.
We have a (free) product that may help you. ProGet gives you the ability to host a custom NuGet feed on your own network, and allows you seamlessly connect to an existing feed such as the NuGet.org one with a "connector". If you publish to the official NuGet gallery and enable caching on your private feed in ProGet, anytime you consume your own package from the official NuGet feed it will automatically cache it (and any others) on your network for you.