[Feature]: Ability to specify relative path on nuget push

[bgreman]

NuGet Product(s) Involved

NuGet.exe

The Elevator Pitch

I propose adding another parameter (and perhaps configuration option) to nuget push. This parameter (perhaps -DestinationRelativePath or similar) would allow use of the -Source parameter to specify a configured Package Source, and then the remainder of the PUT request would be built by concatenating the package source and the value of the DestinationRelativePath. So if one's Package Source called MyNuGetSource was configured with the URL https://mynugetserver.com/api/nuget/v3/my-nuget-repo and one executed the following:

nuget push MyPackage.nupkg -Source MyNuGetSource -DestinationRelativePath MyPackage/1.1The eventual PUT request would be tohttps://mynugetserver.com/api/nuget/v3/my-nuget-repo/MyPackage/1.1/MyPackage.nupkg`

NuGet would still use the credentials specified for the MyNugetSource Package Source, including any stored credentials and client certificate information. Currently this is impossible with regard to client certificates.

Additional Context and Details

NuGet push allows pushing to any arbitrary NuGet repository URL using the -Source parameter. Alternately, the NuGet CLI can store configuration for a given Package Source, including authentication information (username/password, client certificates, etc). However, if one attempts to push to a location that is a sub-path of an existing configured Package Source, NuGet is unable to recognize this and use the configuration for that Package Source.

For example, if I have configured a Package Source called MySource as follows:
<add key="MyNuGetSource" value="https://mynugetserver.com/api/nuget/v3/my-nuget-repo"/>
and I then attempt to perform the following:
nuget push myPackage.nupkg -Source https://mynugetserver.com/api/nuget/v3/my-nuget-repo/subDir1/subDir2, the NuGet CLI does not recognize that this is a subPath of my configured MyNugetSource source, and thus will prompt for credentials if the server side requires authentication. This can be an issue for automated builds, though credential providers could theoretically work around this issue, or one could pass an apiKey on the command line. What cannot be worked around is if the server requires client certificate authorization, since those options can only be specified in the NuGet config file, and not on the command line.

Why might one want to use a relative path in the nuget push? One reason is if their repository target doesn't function the way NuGet.Server does. NuGet.Server will create an appropriate folder structure and place the pushed package into the correct location within it. For example, in Artifactory NuGet repos, a simple nuget push will result in the package being dropped into the root of the repository. For large repos, this can be troublesome.

[heng-liu]

Hi @bgreman , I think this is a duplicate of #10157. Please let me know if you disagree.
Adding any context/upvotes there is helpful: #10157

[bgreman]

@heng-liu I do not think this is a duplicate, that one seems to be referring to relative paths for where the packages to be pushed are currently located when also using a wildcard pattern for which packages to push, not a relative path for the destination sub-path within the targeted remote Package Source. The example command in #10157 doesn't even specify the -s or -Source parameter.

[ghost]

@heng-liu please reopen this, it is not a duplicate.