Retention policy doesn't clean out stuff deployed before policy was applied

Hey guys, just upgraded to 3.16.1 and discovered the retention policies feature. I’ve applied “Files on Tentacles: Keep 5 releases” to my “Default retention policy” and made sure one of my Lifecycles is using the same setup. When I’ve deployed a release in a project that uses the Lifecycle with the retention policy, I don’t see the clean up of the files on the Tentacle under after I’ve released 5 times and it only cleans up within those last set of releases since applying the policy and does not clean out the folders/files that were there for the last month. For example:
15980.0.0 - created before policy
15981.0.0 - created before policy
15985.0.0 - created after policy
15985.0.0_1 - created after policy
15985.0.0_2 - created after policy
15985.0.0_3 - created after policy
15985.0.0_4 - created after policy
15986.0.0 - created after policy

When I run a deploy it will remove 15985.0.0 (greater than 5 releases) but NOT 15980.0.0 & 15981.0.0 (not sure why they don’t get cleaned out)

Let me know if it’s possible to for the retention policy to apply to releases pushed before the policy. Thanks!

-Mike

Hi Mike,

Thanks for getting in touch!

The retention policy will apply retroactively for any releases, so unless we have come across an odd edge case/bug I highly doubt that this is what is occurring here. What I suspect is happening is that something may have gone wrong with your deployment journal at some point which is why the policy appears to not be applying correctly.

Can you please run through the troubleshooting steps outlined in our Tentacle retention policy support page and advise if the issue still remains or if you run into any problems with any of the steps?

Sorry that you are having issues, I am happy to assist further if you have any questions or issues,

Regards

Alex

Finally got around to checking and it looks like you are correct. I’ve run the PS script in that link and commented out the delete and it looks like it should work based on what I see in the logs if I add this as a Custom Script step in a deployment. Do you know if it would be possible to run that script as part of the Machine Policy’s custom scripts? I tried and it was unable to resolve $OctopusParameters[“Octopus.Tentacle.Agent.ApplicationDirectoryPath”] and failed.

Thanks,
Mike

Hi Mike,

Thanks for the update, I’m glad to hear that we found the issue!

As for including it as part of your Machine Policy, the reason that this is failing is that the health checks run outside of Calamari (which is our communications layer). This results in some behavioral differences as compared with the normal scripting in Octopus that you would be accustomed to. You can still use the standard # variable substitution syntax, however since this is replaced on the server, environment variables from your target will not be available through Octopus variables. "Octopus.Tentacle.Agent.ApplicationDirectoryPath" is run on the target, which is why it’s failing in this context.

If you know all your Tentacles are installed with the default application path (C:\Octopus\Applications) you should be able to hardcode this variable to workaround this issue.

$applicationDirectoryPath = "C:\Octopus\Applications"

Let me know if there is anything else I can assist with,

Regards,

Alex