Apply Retention Policy fails often - failing important deployment

We have high availability Beta site that we’ve been having some issues with during deployment. At least 50% of the time the Applying Retention Policy begins running during the middle of the deployment and fails on one of 2 machines (it’s always 1 of these 2 - out of 10 machines). This is causing a lot of issues - the site stops deploying in the middle where everything is on the floor and we need to scramble to get remaining steps executed and site restarted. I’m sure this is some kind of intermittent networking issue on our network (trying to track it down), but the way this retention is run has several issues:

  • it cannot be skipped like a normal step
  • you cannot control what will happen on an error with this step
  • you cannot control when it will run

All of the above allows this to blow up our deployment IN THE MIDDLE with no ability to control it (short of not cleaning up our packages on tentacles)

I’m asking for an Enhancement Request for more control of this “shadow-step” in deployments.

Error we are seeing is this: An error occurred when sending a request to ‘https://mytentacle:10933/’, after the request began: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

We are tracking down the issue, but in the meantime the inability to control this step is causing issues.



Thanks for getting in touch. Octopus applies the retention policy after the last package step is executed therefore it could happen at any point in a deployment. To ensure it happens at the end of your deployment, I’d suggest adding an extra package step that doesn’t have to to do anything (the package contents could be a single text file) as the last step of your deployment. That way, the retention policy won’t be applied it has been executed.

Hope this helps!