`dotnet nuget push --skip-duplicate` does not work as expected

fool

dotnet nuget push added the --skip-duplicate option:

When pushing multiple packages to an HTTP(S) server, treats any 409 Conflict response as a warning so that the push can continue. Available since .NET Core 3.1 SDK.

This works as expected with nuget.org, where trying to push a duplicate package version returns a 409 Conflict and is skipped without breaking the build.

This does not work with ProGet, probably because this option is fairly new?

atripp

Overwriting packages in NuGet.org is totally impossible, but it's possible in ProGet if you have the correct privileges. This is why ProGet returns a 401 (not authorized). We're a bit skeptical to change, but will consider it in a major release.

To be honest, this flag on dotnet nuget push doesn't make much sense, even for NuGet.org. What's the usecase? What sort of Build process is used that doesn't generate new package numbers on build?

We don't like encouraging poor workflows. For example, this is why we don't have a "easy package delete" function; this isn't something you should be doing very often that you'd need a quick-delete, and if you are, your'e probably doing it wrong.

So hopefully you can help us understand this workflow and why it would make sense to use?

kemeny.attila_7338

I found this thread while looking for solution of the exact same problem to OP has.
In our case this feature is not essential but a nice-to-have. For example when the CI pipeline is broken after the nuget artifact was pushed, rerun the build will fail again at the step of nuget push. With this settings all builds could be idempotent and could be run as many times as necessary. Which is a big plus for us.

I understand you don't want to do changes which are not backward compatible. Isn't it possible to add an option or settings where the user can choose the HTTP response code of the response when the package is already exists? In this case if the default value is 403, the change will be backward compatible and can be release faster.

atripp

We have a new major release coming up, 5.3. So perhaps, we'll just change the response there.

And if it actually makes a problem, and others have a trouble updating their own scripts, then we can consider adding a flag.

fool

The use case is quite simply for re-trying a build after a partial (possibly transient) failure, where multiple artifacts are "uploaded", not just NuGet artifacts.

The point is you still cannot (and must not) overwrite any NuGet artifacts with a given version, but you can skip them, which makes the build much more flexible.

cfrolik_9952

@atripp --skip-duplicate is still not working with ProGet 5.3.2. To be clear, the behavior I'm expecting is "publish this package only if this version doesn't exist yet, otherwise do nothing." It appears that even with --skip-duplicate, package versions are overwritten which is not ideal.

atripp

In this case, you'll need to remove the Feeds_OverwritePackage privilege from the API Key or User that's doing the push. The behavior you want/expect is not possible otherwise.

nuget.exe does not send any information to ProGet about whether packages should or shouldn't be overwritten; the --skip-duplication option merely treats certain server errors (i.e. a 409 error) as a warning instead of a failure.

cfrolik_9952

@atripp Thank you for the quick response. It's not obvious to me how to change this permission to API Keys, the checkboxes in the web UI are labelled:

Grant access to Native API
Grant access to Package Promotion API
Grant access to Webhooks API
Grant access to Repackaging API
Grant access to Feed Management API
Grant access to Connector Health API
Grant access to Feed API

I'm guessing there's another place I need to go to remove the Feeds_OverwritePackage from the API key, but it's not obvious how to do this in the web UI.

atripp

Ah, I can see that.

So, in this case, you'd want to:

Grant access to Feed API
Specify a Username to impersonate with the appropriate access to feeds/tasks

prnei_4140

I am having problems configuring a user with the appropriate access. Specifically, I am having problems creating a Task that has the Add Package and View Feed permissions but that does not have the Overwrite Package permission.

We are running ProGet Free Edition version 5.3.2 (Build 14). When creating / editing a task, if I check any of the feeds permissions and save the task, the task saves with all of permissions instead of only the ones I checked.

prnei_4140

I experimented with the "Administration" and "Credentials" categories, along with the "Feeds" category, in the Edit Task UI.

All 3 categories exhibit the bug. If you check any box in the category and save the task, all of the permissions in that category are enabled.

It looks like within a category on the Edit Task UI, all of the input check boxes have the same name. e.g. All 8 check boxes in the Feeds category have the name "ah0~ah4~ah2~ah9".

cfrolik_9952

@atripp I am having the same problem as @prnei_4140 in that I cannot add only one of the permissions; they all get added automatically. Is this a known issue?

atripp

Hello; this issue is known now, I've logged an issue and we'll get it fixed in the next release; PG-1727

Release is scheduled for Friday, but we may ship it sooner.