Octopack 'The server committed a protocol violation' nuget error

Integration
1

Hi

For over a year teams have been intermittently experiencing the following error when using OctoPack via Jenkins build on a variety of build slaves.

This happens randomly and I get the dev guys to run their build scripts off their dev machines in which case Octopack & embedded nuget.exe publish to the Octopus library no problem.

There was a previous thread here

https://help.octopusdeploy.com/discussions/problems/49247-timeout-when-pushing-to-octopus-deploy-server-using-octopack

about a problem with the bundled version of nuget.exe not obeying timeouts, but we are using Octopack 3.6.3 which superceded this issue, and the problem is not a timeout problem it appears.

There are no proxies between the various build boxes and the Octopus server.

Any ideas?

To me it looks like some networking\connection issue…???

Cheers,
Mark

==========Jenkins output===========
… beginning of build output trimmed…
…
OctoPack: Added file: bin\RabbitMQ.Client.xml
OctoPack: Added file: bin\Microsoft.Diagnostics.Tracing.EventSource.xml
OctoPack: NuGet Version: 3.5.0.38733 (Custom build for OctoPack. See http://g.octopushq.com/VersioningInOctopusDeploy)
OctoPack: Attempting to build package from ‘Person.Api.Service.nuspec’.
OctoPack: Successfully created package ‘D:\Jenkins 2\slave-autodeploy\workspace\Person Service - Build and Package\Person.API.Service\obj\octopacked\Person.Api.Service.1.0.0.195.nupkg’.
OctoPack: Copy file: D:\Jenkins 2\slave-autodeploy\workspace\Person Service - Build and Package\Person.API.Service\obj\octopacked\Person.Api.Service.1.0.0.195.nupkg
OctoPack: Packaging finished successfully
Publish to repository: http://dapautodep01/nuget/packages
“D:\Jenkins 2\slave-autodeploy\workspace\Person Service - Build and Package\packages\OctoPack.3.6.3\build\nuget.exe” push “D:\Jenkins 2\slave-autodeploy\workspace\Person Service - Build and Package\Person.API.Service\obj\octopacked\Person.Api.Service.1.0.0.195.nupkg” API-NCC8ZMBTBHMELSOKI3CTUVUANE -Source http://dapautodep01/nuget/packages -Timeout 55000
NuGet Version: 3.5.0.38733 (Custom build for OctoPack. See http://g.octopushq.com/VersioningInOctopusDeploy)
Pushing Person.Api.Service.1.0.0.195.nupkg to ‘http://dapautodep01/nuget/packages’…
PUT http://dapautodep01/nuget/packages/
An error was encountered when fetching ‘PUT http://dapautodep01/nuget/packages/’. The request will now be retried.
An error occurred while sending the request.
The server committed a protocol violation. Section=ResponseStatusLine
PUT http://dapautodep01/nuget/packages/
An error was encountered when fetching ‘PUT http://dapautodep01/nuget/packages/’. The request will now be retried.
An error occurred while sending the request.
The server committed a protocol violation. Section=ResponseStatusLine
PUT http://dapautodep01/nuget/packages/
The server committed a protocol violation. Section=ResponseStatusLine
D:\Jenkins 2\slave-autodeploy\workspace\Person Service - Build and Package\packages\OctoPack.3.6.3\build\OctoPack.targets(109,5): error MSB3073: The command ““D:\Jenkins 2\slave-autodeploy\workspace\Person Service - Build and Package\packages\OctoPack.3.6.3\build\nuget.exe” push “D:\Jenkins 2\slave-autodeploy\workspace\Person Service - Build and Package\Person.API.Service\obj\octopacked\Person.Api.Service.1.0.0.195.nupkg” API-NCC8ZMBTBHMELSOKI3CTUVUANE -Source http://dapautodep01/nuget/packages -Timeout 55000” exited with code 1. [D:\Jenkins 2\slave-autodeploy\workspace\Person Service - Build and Package\Person.API.Service\Person.Api.Service.csproj]

==========Jenkins output===========

2

HI Mark,

Thanks for getting in touch, and my apologies for the slight delay in responding.

Yes, I concur. From the intermittent nature, it does look like it may be a networking issue. The way to track it down for sure would probably be running network troubleshooting tools from the agents in question and see if you can pin down the behaviour - things like running long timeout ping traces and seeing if there are obvious dropouts, and running packet inspectors like maybe wireshark, see if there’s a lot of TCP dropouts and retries.

From the Octopus side, probably not a lot we can do if it does prove to be network issues, but you could try using the octo pack command (from the octo.exe CLI tool), rather than octopack, which tends to be our more up-to-date recommendation.

Thanks

Jason

3

Hi Jason

Thanks for getting back to me…

Cheers,

Mark