How to stop retention policy blocking my deployment

My deployment keeps jumping straight to the Apply Retention policy step after step 5, which locks teh deployment since the service it is deploying is not stopped and still running.

This is super annoying.

How do I stop this?

Hi Dylan,

As @Shannon_Lewis mentioned in the Octopus community slack the way to achieve this is to disable retention policies for this lifecycle.

The reason the retention task runs when it does comes down to two factors. The first is that we assume that retention has been set so that we only clean up old packages that are no longer in use (as retention is off by default and needs to be manually enabled). The next reason is that we don’t want to get to the point where we inadvertently fill up disks, so the retention task is run as soon as possible in the deployment, which is immediately after the package deployment occurs.

Sorry that this caused issues with your deployments, please let me know if you have any further questions!


So, thanks for the feedback. I would love for the option to run this later. Our situation is that we do frequent deployments in dev, fewer in staging, and only occasional in production, and this retention policy issue arises in production because of the large time gaps between deployments.
Obviously a process that works fine in dev, works 90% in staging, but usually fails in Production, is very suboptimal.
Giving users a little more control over when the retention policy stuff is run, or at least allowing it to fail gracefully, would be a big help. Please pass this on.

I just wanted to add that the ability to override retention policy for individual projects/environments would also assist.

Our lifecycles are widely reused, so simply disabling the retention policy will affect a number of unrelated projects that I now need to check, or I need to create a new lifecycle for each project.

Further, our retention policy is strict because of the frequent development environment releases. If I disable the retention policy we risk filling our dev servers drives very quickly and breaking the deployment process at the dev end. This is admittedly better than breaking it at the production end which is what is happening now, but is also suboptimal. If I could apply a strict policy in dev environments, and loosen it in prod and staging, that would be an improvement.

Hi Dylan,

Thanks for taking the time to provide context around how this is affecting you, that is greatly appreciated! I have passed the information through to the engineering team to see if we can make some improvements in this area, so stay tuned to our upcoming releases.

In the meantime, if there is anything else that I can help with, please let me know.


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