# Deploy Package step - Recursive Unzip

Hello,

I noticed a bug (or seemingly so) when deploying custom zip packages. If you deploy a .zip package to a custom Install Directory, where the .zip package contains a nested zip in it’s contents, both zip folders will be extracted to the destination directory. I believe this is incorrect; only the source directory should be extracted. In the example of the attached zip, you’ll end up with the following:

c:\myCustomBuildPath\test
c:\myCustomBuildPath\test\item
c:\myCustomBuildPath\test\package
c:\myCustomBuildPath\test\item\test.txt
c:\myCustomBuildPath\test\package\nestedZip.zip

Desired result is this (no ‘item’ folder):
c:\myCustomBuildPath\test
c:\myCustomBuildPath\test\package
c:\myCustomBuildPath\test\item\test.txt
c:\myCustomBuildPath\test\package\nestedZip.zip

For clarifty: the feature I am referring to is described here:

.zip and .tar are widely supported formats. They are supported natively on many operating-systems, and there are many third-party utilities available.

Thanks,
Travis

testPackage.1.0.0.0.zip (264 Bytes)

Version info:
{“Octopus.Version”:“3.4.9”,“System.OSVersion”:“Microsoft Windows NT 6.2.9200.0”,“System.ClrVersion”:“4.0.30319.42000”,“Process.WorkingSetBytes”:218488832,“Process.ThreadCount”:20,“Process.Uptime”:“21.00:38:28”}

Hi Travis,

Thanks for getting in touch! Just letting you know that I have replicated this issue using your package. I have passed it onto one of our developers who are going to check it out when they are back online in the morning. As soon as I hear from them I will give you an update with an explination as to what is happening or a workaround.

Best regards,
Daniel

Hi Travis,

Sorry for the delay in getting back to you.

I’ve investigated the issue, and unfortunately its a known issue with the library we use, SharpCompress. I’ve logged an issue for us to investigate further and try and come up with a solution.

In the meantime, all I can suggest is either re-organising the package so that there are no nested zip files, or renaming the nested zip file before compression, and using a post-deployment step to rename it back to the desired name.

Sorry that I cant give you better news.

Regards,
Matt

Hi All,

Unfortunately this issue as progressed further, to the point that it is creating build deployment issues. As it turns out, if you create a package that contains nested zip files, files that are processed alphabetically after the zip file will not be processed at all as part of the deploy (or that’s what it appears anyway). To replicate, try deploying the package I attached and you’ll see zz1.txt and zz2.txt do not get deployed. This also appears to be true of folders at the same level as the zip, in addition to files, which is the real issue for us.

I read on the thread above “Turns out we didn’t need to use the streaming ZipReader - ZipArchive works well for us.”. Does that mean this is fixed in a current or future release of Octopus Deploy?

Eagerly awaiting a resolution, as this creates deployment problems for us going forward.

Thanks,
Travis

Update: looks like only zip1.zip was deployed, and zip2.zip did not deploy at all (in addition to zz1.txt and zz2.txt not deploying). Note that the extraction of ‘subzips’ is not desired, but is acceptable. The primary issue is the folders and files alongside the subzip in a later alphabetical sort order not deploying at all.

Okay, one last update. It appears that the contents of zip1. are missing from the zip as well, and the ‘husk’ of the zip is left (contents extracted outside the directory). That doesn’t make a lot of sense to me, and could possibly result in an issue during deployment. It looks to me that this entire functionality really needs to be overhauled. Removing nested zips from our packages is undesirable, and will impact the deployment in a negative way. For that reason, I would prefer not to entertain that solution. It also may not be possible at all in some cases.

It seems odd to me to think that a package would never contain a zip, although it is admittedly not a perfect package design. Worst case I can write the deployment step logic myself, but it’s really nice to have Octopus handle it so the versioning is kept intact throughout; that’s one of the significant value adds of Octopus here.

Thanks for your help on this,
Travis

Hi Travis

Apologies for not getting back to you on this. As you found in the other thread, we switched over to ZipArchive rather than ZipReader and from our testing, it resolved the nested zip problem.

This change was released in 3.5.2. Can you try upgrading to the latest and let me know if it resolves the issue for you?

Hope that helps!

Regards,
Matt

Great news! I’ll give that a shot.

Thanks,
Travis

This has been both tested and resolved on Octopus Server 3.6; thanks so much for your help and the prompt / effective solution. Keep up the great work guys!

Hi Travis,

Great to hear. Glad its resolved for you.

Happy deployments!

Regards,
Matt