Home: `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

[aliostad]

@StefH huh, I found the -n needs a value i.e. -n true which is just bad and lazy but once doing that it works.

[donnie-msft]

@aliostad Thanks for pointing out that bug! I found this is being tracked here https://github.com/NuGet/Home/issues/4864

[aliostad]

@donnie-msft Thanks yes, I did find that. As for this issue, I think using -n true works hence there is a real workaround.

[donnie-msft]

Here's my findings and plan for resolving this issue. Discussed with @rrelyea, @karann-msft, and @cristinamanum.

Wildcard doesn't find snupkgs

Existing behavior: We have always failed with "File does not exist" during a push to a symbol source where a * in the path was used, yet there were no snupkgs in the directory (having 1 or more snupkgs would succeed).

Behavior change:

• [x] Going forward, anytime we automatically push snupkgs when pushing nupkgs, we do not error if there are no snupkgs are found. (We are quiet about snupkgs).

Explicitly pushing snupkgs will continue to error if the directory contains no snupkgs.

Push explicit snupkg where file doesn't exist

Existing behavior: Pushing "NotFound.snupkg" currently results in no CLI output (even with detailed verbosity), where the equivalent push using a "NotFound.nupkg " results in "File does not exist".

Pushing *.snupkg correctly shows "File does not exist (…*.snupkg)".

Behavior change:

• [x] Pushing an explicit snupkg filename that does not exist will error.

Duplicate snupkgs

Existing behavior: Snupkg duplicates can behave differently than nupkg duplicates (as is the case with nuget.org):

• If a snupkg already exists when pushed, nuget.org will simply overwrite it, validation will be re-ran on this snupkg, and a success response (HTTP-201) is returned.

• A special case is if server validation is currently executing on this snupkg (as it does immediately after a push), another push of the snupkg causes the server to return this duplicate error:

Response status code does not indicate success: 409 (It looks like there is another copy of this symbols package pending validation(s). Please wait for the validation(s) to finish before trying to replace the symbols package.).

Behavior change: We will split this error to be more consistent with how nupkg duplicate responses are handled:

Without SkipDuplicate (unchanged):

Conflict https://www.nuget.org/api/v3/package/ (61ms)

• [x] With SkipDuplicate:

  Symbols Package 'C:\MyApp12.1.0.2.snupkg' already exists at feed 'https://dev.nugettest.org/api/v2/package'.

• [x] With Verbosity: detailed In either case above, show any message from the server accompanying the 409
  For example, nuget.org would show:

Info: It looks like there is another copy of this symbols package pending validation(s). Please wait for the validation(s) to finish before trying to replace the symbols package.

[RehanSaeed]

I just got this for a nupkg which contains project templates which definately will never have a snupkg.

Is this fixed in 5.5-preview1 and do I need to pass --no-symbols in that version?

[anangaur]

@donnie-msft, is it making to 5.5 preview 1?

[donnie-msft]

I just got this for a nupkg which contains project templates which definately will never have a snupkg.

Is this fixed in 5.5-preview1 and do I need to pass --no-symbols in that version?

Hi @RehanSaeed, 5.5 preview 1 has already shipped, and this change has not been merged quite yet.
I'm expecting it to be in 5.5 preview 2

There will be no need to pass --no-symbols unless you do not want to push symbols at all (this means do not even attempt it).

The point of this change is if you want to push nupkgs, and there are snupkgs available, they will be pushed if they are present, but will not cause an error if they are missing.

[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 https://github.com/NuGet/NuGetGallery/issues/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: https://github.com/NuGet/Home/issues/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