hello
When i am running the following command line :
D:\BuildAgent\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe push D:\BuildAgent\work\f281e2ce34e8a514\Tests\Geosys.PAg.WebApi.DeployTests\bin\Release\Geosys.PAg.WebApi.DeployTests.3.1.14.0.nupkg [my api key that i wont share] -Source http://octopusserver/nuget/packages -verbosity detailed
i have the following error :
Pushing Geosys.PAg.WebApi.DeployTests 3.1.14.0 to ‘http://teamcity-srv:81/nuget/
packages’…
PUT http://teamcity-srv:81/nuget/packages/
System.InvalidOperationException: Failed to process request. ‘Bad Request’.
The remote server returned an error: (400) Bad Request… —> System.Net.WebExce
ption: The remote server returned an error: (400) Bad Request.
at System.Net.HttpWebRequest.GetResponse()
at NuGet.RequestHelper.GetResponse()
at NuGet.HttpClient.GetResponse()
at NuGet.PackageServer.EnsureSuccessfulResponse(HttpClient client, Nullable1 expectedStatusCode) --- End of inner exception stack trace --- at NuGet.PackageServer.EnsureSuccessfulResponse(HttpClient client, Nullable1
expectedStatusCode)
at NuGet.PackageServer.PushPackageToServer(String apiKey, Func`1 packageStrea
mFactory, Int64 packageSize, Int32 timeout, Boolean disableBuffering)
at NuGet.PackageServer.PushPackage(String apiKey, IPackage package, Int64 pac
kageSize, Int32 timeout, Boolean disableBuffering)
at NuGet.Commands.PushCommand.PushPackageCore(String source, String apiKey, P
ackageServer packageServer, String packageToPush, TimeSpan timeout)
at NuGet.Commands.PushCommand.PushPackage(String packagePath, String source,
String apiKey, TimeSpan timeout)
at NuGet.Commands.PushCommand.ExecuteCommand()
at NuGet.Commands.Command.Execute()
at NuGet.Program.Main(String[] args)
The error is not helping me, is there a way to see more on the issue, logs in octopus nuget built in repo, i dont know where to look at.
Thanks
Hi Sebastien,
Thanks for getting in touch! That “Bad Request” error generally indicates that the version of the NuGet package being pushed already exists in the the NuGet repository. It’s not terribly descriptive but it’s a part of the NuGet plumbing we utilise for the build-in repository. This looks like it’s a part of your team city build process and you might be pushing the same package twice. If you can’t find the error, you can attach your build log here and I can try to help you find the issue.
Hope that helps!
Rob
thanks is there a way to overwrite or skip an existing nuget package so i wont have this blocking issue ?
Hi Sebastien,
Thanks for the reply. Unfortunately, the NuGet push pipeline does not support overwrite or skip. The best way to avoid it is to ensure your build is producing packages with unique version numbers or have the push as a final step when all builds and tests have completed.
Hope this helps!
Rob
Hello
i am not sure i understand " have the push as a final step when all builds and tests have completed".
I am using the nuget push at the end of a teamcity build to push a nuget package of the application i want to deploy. the versionning is done manually in the assemblyinfo, the nuget package is created by octopack. Having a unique version number would not work in my case as we are changing the version mannually when there is something stable to ship.
Hi Sebastien,
Thanks for following up. I mentioned doing a the NuGet push at the end of your TeamCity build because there can be a timing issue resulting in pushing an older version of a package when the latest version isn’t available yet. If you’re doing this, then it shouldn’t be an issue.
I would recommend using TeamCity to help manage your versions (AssemblyInfo patcher is excellent for this) as you could use it to append a build number to make the version number unique however if this isn’t possible, then your best option is to create a separate build configuration to manually push previously built packages to octopus once the version is unique.
The NuGet ‘Really brief introduction to SemVer’ is a great read on the subject.
Using a structure like Major.Minor.Patch-Something communicates a lot about the stability and contents of a release. The ‘-Something’ string indicates it’s a pre-release and it can be anything you want. Something like 1.5.6-internalbuild1234 where the 1234 is the TeamCity build number works great. Reusing version numbers makes it difficult to tell the difference between binaries from different builds and can cause issues (broken builds) with downstream dependencies.
Hope this helps!
Rob