nuget push *.nupkg fails when snupkg does not exist

[karann-msft]

I am trying to push a bunch of nupkg which do not have snupkg, using nuget.exe 5.1.0,

C:\Users\karann\Downloads\skipduplicate_test>nuget push *.nupkg -source nuget.org -SkipDuplicate
Pushing calchelper.1.0.1.nupkg to 'https://dev.nugettest.org/api/v2/package'...
  PUT https://dev.nugettest.org/api/v2/package/
  Conflict https://dev.nugettest.org/api/v2/package/ 698ms
Package 'C:\Users\karann\Downloads\skipduplicate_test\calchelper.1.0.1.nupkg' already exists at feed 'https://dev.nugettest.org/api/v2/package'.
Pushing CalcHelper.Foo.1.0.1.nupkg to 'https://dev.nugettest.org/api/v2/package'...
  PUT https://dev.nugettest.org/api/v2/package/
  Conflict https://dev.nugettest.org/api/v2/package/ 258ms
Package 'C:\Users\karann\Downloads\skipduplicate_test\CalcHelper.Foo.1.0.1.nupkg' already exists at feed 'https://dev.nugettest.org/api/v2/package'.
WARNING: Found symbols package '*.snupkg', but no API key was specified for the symbol server. To save an API Key, run 'NuGet.exe setApiKey [your API key from http://www.NuGet.org]'.
WARNING: No API Key was provided and no API Key could be found for 'https://dev.nugettest.org/api/v2/symbolpackage'. To save an API Key for a source use the 'setApiKey' command.
File does not exist (*.snupkg).

Expected: no warnings or errors related to snupkg should show up if no snupkgs are found in the path.

Update: @donnie-msft added more info and tasks in this comment

[rrelyea]

@donnie-msft - can you confirm if this is a new break in 5.1, please?

[donnie-msft]

Confirmed as not a new break, but the Warnings about snupkgs do not make sense and should be fixed.

The Warning regarding symbols is due to a recognition that the Source can accept symbols, and it then incorrectly assumes there are snupkgs being pushed when there aren't (like in this case).
The API key was specified in a nuget.config,

SkipDuplicate is not coming into play, as it is only allowing the code to continue until it hits the warnings above.

[Tychus]

Having this issue building and publishing packages, packages are published to our private repository but the Jenkins jobs fail because of the "*.snupkg" issue. when can we expect a fix ?

[donnie-msft]

Having this issue building and publishing packages, packages are published to our private repository but the Jenkins jobs fail because of the "*.snupkg" issue. when can we expect a fix ?

@Tychus,
What command are you executing to get this behavior, and do you have snupkgs in the directory to push, or no? Also, is your private repo a file system repo, or a private server? Logs would be helpful as well.

This issue is only about a Warning, which doesn't sound like it should fail something like Jenkins, AFAIK. Not sure it's relevant, but curious if somewhere you have a setting like "Treat Warnings as Errors" enabled?

[Tychus]

new to nuget packages, we use nuget cli on a windows slave. executing nuget.exe push ... with a key returns exit code 1 making the job fail.

Your package was pushed. File does not exist (C:\Users\Jenkins\Documents\JenkinsWork\workspace\Common\XXXXX.snupkg). C:\Users\Jenkins\Documents\JenkinsWork\workspace\Common>exit 1

we fixed this by ignoring the return of the command since it always pushes the packages we need. Don't think we have fail on warnings as other build steps generate warnings but never broke builds.

[anangaur]

I hit the same issue today. Details here: https://github.com/anangaur/entropy-packages/commit/c3a21773faa4d2d6f250e2906be91bb201627e2d/checks

[olsh]

I have the same issue with dotnet nuget push
https://github.com/olsh/sentry-api-client/runs/229034352

[knocte]

I was hit by this issue today. Even downloading older version of nuget (4.5.1) didn't fix the problem. But I've found a workaround: don't use wildcards (*.nupkg), just use the exact file name.

[StefH]

@knocte Any news, or is it still required to use the exact filename?

[StefH]

Could this help? (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-push)

-n|--no-symbols

Doesn't push symbols (even if present).

[aliostad]

Could this help? (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-push)

@StefH no, I had tried it. No help despite it really should

[aliostad]

Having the same issue

[Aarklendoia]

In addition to this problem, if a symbol package is available, it is always pushed even if the SkipDuplicate option has been added. We have the following error on the nuget.org side because the package and symbols no longer match.

Symbols package publishing failed. The associated symbols package could not be published due to the following reason(s):
The uploaded symbols package contains one or more pdbs that are not portable.
Once you've fixed the issue with your symbols package, you can re-upload it.

Please note: The last successfully published symbols package is still available for debugging and download.

If both packages are pushed at the same time (e. g. due to a version change), the problem does not occur.

[donnie-msft]

Merged and should go out in 5.6 Preview 2.

In addition to this problem, if a symbol package is available, it is always pushed even if the SkipDuplicate option has been added.

Quick clarification about this PR:
-SkipDuplicate was not applying to the automatic snupkg push (when pushing nupkgs) before this change. The option will be available now, and if you want to see the detailed output you provided (eg, validation in progress) , you can now specify -Verbosity detailed.

@Aarklendoia Your scenario sounds a bit different. I'm curious, how are you packing your nupkg/snupkg before you re-push them?

I think there's confusion in what SkipDuplicate does in this case. It does not actually prevent a snupkg from being uploaded to the Server. It will simply ignore any response code that indicates "Conflict".
However, nuget.org will always accept snupkgs and try to process them (I raised an issue to discuss this behavior NuGet/NuGetGallery#7681). That's why you're getting that error. SkipDuplicate does not proactively check a Server to see if there's a snupkgs.

Docs should be clarified, so please comment on this issue to provide your feedback: #9338

[obarlik]

Adding "-NoSymbols" to nuget push command fixed my issue.
https://docs.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-push

[donnie-msft]

I believe dotnet.exe 3.1.3xx contains this change https://github.com/dotnet/cli/pull/13324/files