Dear Octopus support,
I have a question regarding the package retention on tentacles.
I noticed that all packages are kept in a directory on the tentacle and then unzipped to the _applications\tenants folders per version deploy. As we use a custom deployment directory, this means that eventually the same package is unzipped double on our drives per tenant and eating useless disk space.
I checked the retention policy but setting it 1, this keeps the current version and the previous version. You can’t go down to only 1 (0 is keep all releases) and I didn’t find another way to automatically cleanup the packages on the tentacles through Octopus.
Is there a way to cleanup these unzipped packages per tenant even further after deployment? Down to 1 or even none unzipped as the actual package is kept elsewhere on the server as well?
Thanks for getting in touch! There is nothing you can set in Octopus that will clean up the current or previous deployment. You can add a script in the deployment process, we have variables you can use if you are interested in this.
The packages being retained allow for the use of delta compression transfers which overall means less network traffic.
Have you considered using the extraction directory instead of the custom installation directory to keep the duplication slightly less?
Thanks for your reply.
How exactly do the delta compression transfers work then? I see a directory on the tentacle for Config/Files which contains all the version files which I could understand are used for upload and delta transfers.
To me it seems like the extraction directory is solely used for extraction, config changes and such before moving to the custom install directory?
Unfortunately using the extraction directory is not an option for us due to our ACL setup and it would also still mean a minimum of 2 extracted versions per tenant.
Maybe it could be an idea for the future to allow the cleanup of these files when using a custom installation directory?
Thank you in advance for your information.
Delta compression works on the package cache to determine if there are any previously uploaded packages to determine if a delta can be made.
It is not in any way effected by the extract directory. While I can absolutely understand you need to have a custom installation directory, extracting a package over this would lead to major issues.
We always extract to a new directory - even if the version of the release exists on the server - because we need a fresh un-accessed location. When files are extracted it is assumed they will be in an incomplete state. That variables need to be substituted, and configuration transforms need to occur. It gives the ability for the extracted files to be completed and ready for access. Extracting over an existing directory could have incomplete or unready files accessed by a live website or service, which is not wanted. We perform all of these tasks and then either re-point IIS to this new directory or in your case move the files to the location you specify. The former considered the best practice in Continuous Delivery. In essence we keep a current deployment and a previous as state instead of backup purposes.
We do see that for Tenants this would lead to a bit of extra duplication depending on the amount of Tenants you have - the extraction directory is the working directory when you use CID. If we deleted them you would also never have a previous - and like I said you are welcome to write a post script that does delete this directory. You are also welcome to add this as a suggestion to our UserVoice site to see how much community support is behind the idea of having no extraction directories when a CID is used, we are always encouraged by votes for extending features. https://octopusdeploy.uservoice.com/