Releases on offline package drops not respecting retention policy

Hey Octopus Team,

When we install a release that was deployed to an offline package drop our retention policy is being ignored, all of the deployment files from previous installs can still be found in the Applications directory.

Is there any way we can make the offline drops respect our retention policy or maybe a script we can execute in our deployment process to automatically delete X releases if the release was deployed to an offline package drop?

Octopus Server version: 2020.1.12
Retention Policy: keep 5 releases, keep 2 releases on tentacle

Kind regards,

Hi @yenti.verle,

This is an interesting concept. I did some testing to make sure I understood exactly what results you are seeing and what you would expect to see.

To make sure we are on the same page and I have understood exactly what you are saying, can you confirm my understanding is correct?
Using this Offline Package Drop Deployment Target as an example:

The “Destination” currently has the retention policy run as expected, so “C:\OPD” is cleaned up according to the policy described.

However, your concern is around the Applications Directory (“C:\Applications”) not being cleaned up according to any retention policies.

When deploying the cmd file (the Offline Package Drop runner) created by Octopus that resides in the destination folder, you would expect this batch file to run a cleanup of the Applications Directory, removing any packages that are now outside of the retention policy set in the Lifecycle. Please let me know if that is accurate.

If so, I will reach out to the engineers to see if this is on their radar. As far as I understand, we don’t have any solutions in place at the moment.


Hey @dane.falvo

You’re exactly right, we deploy the cmd file created by the offline package drop to some of our servers manually. When we do so the Applications Directory on that machine (C:\Applications in your case) is not respecting the policy in our lifecycle.

In my opinion it would make a lot of sense to let Octopus clean this directory as it does clean up if I would run the release on a listening tentacle.

Kind regards,

Hi @yenti.verle,

I’ve now raised this enhancement in our Github issues register.

You can follow along with it’s progression and any updates by subscribing to the issue, using the subscribe button on the right hand side (under “notifications”).

In the meantime, I haven’t been able to find any details about scripts already in existence, that would cleverly clear up the applications folder. The way I would tackle this in the interim, would be to create a step within your Offline Deployment Octopus Project that would remove anything older than x number of days old, from the applications directory.

This would mean that everytime a new package is deployed, the rest of the applications directory would be cleared out. I’m sure you could work out smarter logic on how to clean up packages, etc, but as long as the OPD folders still exist on the deployment target, you will always have the option to redeploy the application from that folder, if you need to.

If you have any further questions, please reach out.


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.