Package upload errors

external
reliability
(walter.gameiro) #1

Greetings - we are using the online Octopus App for some of our deployments. I’m having an issue uploading packages since this morning. Keep getting the error : “Could not find Zip file Directory at the end of the file. File may be corrupted” - I’ve downloaded the nuget package locally and it is fine. The problem seems to lie somewhere inside the Octopus App. Can someone help?

Thanks in advance.

PS - We manually copied the file from our MyGet server with this format (BAS.Nop400.Deploy@S2.1.522@063AA5B7CCDB0E6EE3DBA4B99BB3D8A60047587B.nupkg) on to our deployment node and once the file was in the cache the local server can run the deployment without issue. So this seems to confirm that the file is getting corrupted between our MyGet server and your Octopus server.

1 Like
(Justin Walsh) #3

Hi @walter_gameiro

Just a quick update here, we got your email to support@octopus.com and our team is actively looking into this issue for you. We’ll be in touch as soon as we have more information for you.

(walter.gameiro) #4

Thank you, Justin.

1 Like
(walter.gameiro) #5

For those searching the forums for an answer, I got a reply from Octopus today with an explanation.

It seems there was something in one of our nuget packages that caused Octopus’ Delta compression algorithm to fail and prevented new deployments from working. Basically, Octopus calculates the binary difference between one package and the next to figure out what to send and prevent large uploads. They call this Delta Compression. When we primed the tentacle caches with the new packages the other day, it bypassed the Delta compression algorithm and it “fixed” the problem.

For the future, they are working on making their algorithm more robust.

But if we ever run into this problem again, we can circumvent it by adding a project variable of “Octopus.Acquire.DeltaCompressionEnabled”=“False”

This will bypass the delta compression algorithm and simply upload the full package.

1 Like