During the build task we are getting the following errors on our nupkg. I have checked to ensure that version is not a duplicate . nothing is shown in the Octopus logs for the event or in the Windows logs.
it does not always happen on the first build for a build definition every day but seems out of our 9 build defs, 6 will fail, after that all builds work.
FeatureB\Products\packages\OctoPack.3.6.3\build\OctoPack.targets(109):FeatureB\Products\packages\OctoPack.3.6.3\build\OctoPack.targets(109,5): Error MSB3073: The command "“C:\agent_work\17\s\FeatureB\Products\packages\OctoPack.3.6.3\build\nuget.exe” push “C:\agent_work\17\s\FeatureB\Services\Document Conversion Service\Merchants.DocumentConversionWS\obj\octopacked\Merchants.DocumentConversionWS.2018.2.27.1-featureB.nupkg” ******** -Source http://octopus.merchantsfleet.com/nuget/packages " exited with code 1.
Thanks for getting in touch. It seems that this is unfortunately not the first time we’ve heard of NuGet.exe behaving like this, see Nuget Push Errors, How to Troubleshoot?.
As was mentioned in that other thread, there can sometime be more information further back in the log file, would you be able to check if there are any other error entries further back on the build log?
I’m wondering if it’s related to a timeout or something like that during the push, e.g. if there was a high level of network traffic or something at the time then maybe Nuget.exe times out and returns us that error. Is the package large enough that a timeout could be possible/likely?
I checked early in the build logs and nothing for other error also this occurs at any time of the the day and only seems to happen for the first build of a build definition of that day but not always every day. I have had some of this builds fail in the middle of the night when the load on the network is very low and these server are not busy. I even tried different times for the nightly builds and still get those build failures if it is the first build of the day.
It’s probably a long shot, but would it be possible for you to try using OctoPack to just create the package and then have a second step that uses Octo.exe push to push the package to Octopus?
The subtle difference is that OctoPack uses NuGet.exe to do the push and Octo.exe uses HttpClient. I suspect the issue is actually network related, so like I said it’s probably a long shot, but it may reveal something.
I can’t see anything that looks wrong there. The use of /p:DeployOnBuild=true /p:PublishProfile=Build probably isn’t necessary, OctoPack hooks in to the Build target rather than the Publish target, so there probably isn’t real value there.
I don’t think those arguments would cause what you’re seeing, but it could be worth trying without them. The 409 (Conflict) is what will get returned if that package Id and Version combination already exists in the feed. Is it possible that this same build ran twice or something like that?
This is very intriguing. You said you’d checked it wasn’t a duplicate, was that by checking that version didn’t exist in the Octopus feed for the Merchants.SecurityWS package? Would you be able to attach a screenshot of the versions list from the feed for that package, just in case anything there stands out?
Could I get you to open the nupkg file and check what it shows as it’s version in the nupsec metadata? (either with Nuget Package Explorer or rename it to Zip and extract it to see the nuspec file content). If the version inside the package doesn’t match the filename, for example it’s missing the -main somehow, then this could explain the error you’re seeing.
From that json file, that version is definitely in the feed already.
"Version": "2018.3.21.1-main",
"Description": "Windows service that hosts a WCF service that provides security-related functions",
"Published": "Wednesday, March 21, 2018 2:15 AM",
The Published date shown there is 2:15AM, does that correlate with the time of the failed build?
No my build kicks off at 5:30 am every morning and I see that every 2:15 am that it is in the feed how is that possible when I am not building and pushing that out.
I wasn’t sure you could do an overwrite when using OctoPack, but after discussion with the team I learned that you can. You just need an adjustment to the server Url to include ?replace=true.