Retention policy for Linux tentacles

Ryan_Adler · 13 October 2016 12:12

How do the retention policies currently work on Linux tentacles? I know that the tar.gz package is uploaded to the home folder, and also extracted there. Will retention policies have any effect on cleaning up space there?

Also, do retention policies apply across channels? In other words, if I perform a deployment of the same project over two channels, and my retention policy is set to save only the latest package on the tentacle, will both remain?

Finally, is there a way to tell the retention policy not to keep ANY latest versions on the tentacle? Our packages are extremely large, and we find ourselves running out of space on the /home partition after just a few channels have been deployed.

Michael_Noonan · 14 October 2016 01:26

Hi Ryan,

Thanks for getting in touch! Both Tentacle and SSH targets use the same command for cleaning up during the Apply retention policy phase of a deployment, and they use something like Calamari.exe clean --retentionPolicySet "Environments-2/projects-161/Step-Package B/machines-65/<default>" and either the --days or --releases arguments.

github.com

OctopusDeploy/Calamari/blob/master/source/Calamari/Commands/CleanCommand.cs

using Calamari.Commands.Support;
using Calamari.Deployment.Journal;
using Calamari.Deployment.Retention;
using Calamari.Integration.FileSystem;
using Calamari.Integration.Processes;
using Calamari.Integration.Processes.Semaphores;
using Calamari.Integration.Time;

namespace Calamari.Commands
{
    [Command("clean", Description = "Removes packages and files according to the configured retention policy")]
    public class CleanCommand : Command
    {
        string retentionPolicySet;
        int days;
        int releases;

        public CleanCommand()
        {
            Options.Add("retentionPolicySet=", "The release-policy-set ID", x => retentionPolicySet = x);

This file has been truncated. show original

The class that applies the retention policy uses the deployment journal file to determine what to keep and what to delete: https://github.com/OctopusDeploy/Calamari/blob/master/source/Calamari/Deployment/Retention/RetentionPolicy.cs

Based on that, both Tentacle and SSH retention policies should work exactly the same way as described in our troubleshooting guide: http://docs.octopusdeploy.com/display/OD/Retention+policy+Tentacle+cleanup+and+troubleshooting

In answer to your last question, you can’t configure Octopus to “not keep ANY versions” since the cleanup process deletes both the source and destination folders which would undo all your hard work. What you want to achieve is different to what most customers expect from Octopus.

In your scenario I would suggest adding an [AfterPostDeploy.sh](http://docs.octopusdeploy.com/display/OD/Package+deployment+feature+ordering) script using the [Octopus.Tentacle.CurrentDeployment.PackageFilePath](http://docs.octopusdeploy.com/display/OD/System+variables) variable to delete the massive package. I haven’t tried this in anger myself, but it should give you a good starting place.

Hope that helps!
Mike