Open jmecosta opened 2 years ago
@jmecosta I was able to reproduce the issue using the same command line you used (changing the URLs to the localhost server I was testing with).
I found that by not specifying the --symbol-source <url>
parameter, it actually worked. The server I was using, like nuget.org, includes a SymbolPackagePublish
resource. If Proget's service index (index.json) includes this resource, just like nuget.org's does, then you should not need to specify the symbol source URL on the command line.
But we should not be silently ignoring the symbols package or silently failing, so that needs to be fixed.
@zivkan thanks for confirming the problem
@zivkan maybe related but: https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg
dotnet nuget push TeklaFusion.4.0.4.snupkg --source http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/v3/index.json
also doest do anything. i supose the SymbolPackagePublish is also missing from that source
@jmecosta I just remembered that there have been some changes to push over the last 2 years:
If you're on Windows, it would be great if you could try downloading NuGet.exe versions 5.8 and 6.1 from https://nuget.org/downloads, and try them out (perhaps with the --symbol-source
argument), and let us know if either (or both) of those work. If this used to work and we can narrow down when it broke, it might be easier to fix.
6.2.1.2 not working 5.8.1 not working either 5.9.2 not working either
Just tested this with the current dev branch (6.5) and it is not working either.
@zivkan I don't really think the code you linked could actually work.
This loop here expects a path for every package, one for .nupkg and one for .snupkg. But the command handler calling this method only allows for a single argument to pass through.
But given that .snupkg should be handled automatically without the user explicitly specifying it as an argument, there probably should be some code in between those methods that handles looking for .snupkg next to the supplied .nupkg.
Could you give an update about this issue?
@jwfx we prioritize work based on a number of factors, one of which is upvotes. This issue doesn't have any upvotes yet, so might not have caught the eye of people triaging issues during sprint planning. This issue was created when it was my turn on the support rotation, and I just validated that the issue can be reproduced but support doesn't have enough time to bugfix.
Thank you for the update and for linking that document. Hitting this issue directly from a search engine, that policy totally went past me.
Just for information for anyone else hitting this from search engine:
I just realized that in my case, the issue was in the missing protocolVersion
attribute in the xml of the NuGet source.
To clarify - the follwoing would not work but instead only publish the package on push
:
<add key="Artifactory" value="https://......./api/nuget/v3/xyz-local" />
<add key="ArtifactorySymbols" value="https://....../api/nuget/v3/xyz-local/symbols" />
However, changing the source definition to following:
<add key="Artifactory" value="https://......./api/nuget/v3/xyz-local" protocolVersion="3" />
<add key="ArtifactorySymbols" value="https://....../api/nuget/v3/xyz-local/symbols" />
Magically makes everything work as expected - i.e. a simple nuget push myPackage.nupkg
will now push the package and detect and push the corresponding *.snupkg file.
❗ However - due to #9170 still being open, we now have to manually fix the config file as part of our CI pipeline 😞
@jmecosta
The just released ProGet version 2022.20 adds support for pushing .snupkg automatically together with .nupkg without using the --symbol-source
parameter.
The unexpected behavior of the --symbol-source
parameter in nuget.exe remains though.
can confirm for local pushes
dotnet nuget push a.0.01.nupkg a.0.01.snupkg --source /nuget --symbol-source /snupkg
does
Leaving out the symbol-source parameter, will lead to havinig the snupkg being silently ignored.
dotnet --version
6.0.406
dotnet nuget --version
NuGet Command Line 6.3.2.9
Same issue with nuget 6.6.1.2
, please prioritize.
Just noticed that I'm getting file does not exist
only in unix, executing same command on windows (dotnet nuget push My.snupckg
) DOES pushes it .
Looking here: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Commands/Utility/CommandRunnerUtility.cs#L107-L110
I found when stepping through with a debugger:
if (packageSource == null)
{
packageSource = new PackageSource(source);
}
Should probably be:
if (packageSource == null)
{
packageSource = new PackageSource(source)
{
ProtocolVersion = 3
};
}
This seems to cause the SymbolPackageUpdateResourceV3
to fail to resolve given that it creates a V2 repository by default.
I also cannot find an execution path that sets:
symbolPackageUpdateResource
to a non-null value if a user specifes the symbolSource
if (string.IsNullOrEmpty(symbolSource)
&& !noSymbols
&& !sourceUri.IsFile
&& sourceUri.IsAbsoluteUri)
{
symbolPackageUpdateResource = await CommandRunnerUtility.GetSymbolPackageUpdateResource(sourceProvider, source);
if (symbolPackageUpdateResource != null)
{
symbolSource = symbolPackageUpdateResource.SourceUri.AbsoluteUri;
}
}
After this point symbolPackageUpdateResource
is never assigned to.
Which causes:
bool isSymbolEndpointSnupkgCapable = symbolPackageUpdateResource != null;
To always be false.
I suspect somewhere in here:
// Precedence for symbol package API key: -SymbolApiKey param, config, package API key (Only for symbol source from SymbolPackagePublish service)
if (!string.IsNullOrEmpty(symbolSource))
{
symbolApiKey ??= CommandRunnerUtility.GetApiKey(settings, symbolSource, symbolSource);
// Only allow falling back to API key when the symbol source was obtained from SymbolPackagePublish service
if (symbolPackageUpdateResource != null)
{
symbolApiKey ??= apiKey;
}
}
The symbolPackageUpdateResource
was supposed to be resolved.
What worked for me:
SymbolSource
this cause a failureNuGet.config
with your source:
<add key="Artifactory" value="https://......./api/nuget/v3/xyz-local" protocolVersion="3" />
A.nupkg
file exactly.dotnet nuget push "A.nupkg" -s https://......./api/nuget/v3/xyz-local -k <YOUR API KEY>
NuGet Product Used
dotnet.exe
Product Version
6.0.300
Worked before?
No response
Impact
No response
Repro Steps & Context
Hi,
Ive raised a ticket on our nuget server provider (proget) and they said that "dotnet nuget push" is a "bit" buggy with when using "*" argument... Wanted to report this buggy behaviour here so can help them also clarify a bit the behaviour:
dotnet nuget push --source http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/v3/index.json *.nupkg --symbol-source http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget-symbols/v3/index.json --api-key KEY --symbol-api-key OTHERKEY --skip-duplicate
this pushes only the .nupkg Pushing TeklaFusion.4.0.4.nupkg to 'http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/package'... PUT http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/package/ Created http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/package/ 263ms Your package was pushed.
The TeklaFusion.4.0.4.snupkg is never published or even detect looks like it by the CLI tooling....
thanks in advance for the clarification jorge costa
Ive originally raise ticket on dotnet side, https://github.com/dotnet/sdk/issues/25958 but they closed it .
Verbose Logs
No response