Octopus retention doesn't seem to work fully

Hi support,

First, thanks in advance for looking into my issue, really appreciated. I’m always amazed by your fast responses and knowledge! I have read this topic https://octopus.com/docs/administration/retention-policies a few times before, but I think I found some behavior in our server that doesn’t line up with what is explained here. We have about 55 projects running in octopus, each deployed to 3 or 4 servers, which ends up in a big package folder on the octopus server and there is were I found some things I want to discuss here. To get concrete, at one project we detected the following:

project setup
Development -> Test -> Production

Retention policies
Development & Test have set the retention policies for releases to 1, production to 3.
The default life cycle has set it retention policies to 1 as well.
Non release packages are deleted after 1 day.

For this project, the package folder contains 13 packages (The number is the last 3 digits of the package, in real its much larger, but I dont want to make things more complex)

Package name | Last release environement
422.nupkg | Development
421.nupkg | Development
420.nupkg | Development
419.nupg | No release
397.nupkg | Release, not deployed
393.nupkg | Test
392.nupkg | Test
370.nupkg | Production
367.nupkg | Test
299.nupkg | Production
298.nupkg | Production
286.nupkg | Production

If I understand the documentation correctly, the releases / packages 286, 367, 419,420 should be deleted. How long will 397 be there, only after 2 new package with no release are added? The last package (422) is added/deployed at 5.37. Meaning that the scheduled task which runs every 4 hours should have run by now and delete the packages. So what goes wrong?

How can I force to run that scheduled task now ? (It doesn’t show up in the windows task schedular) Are my assumptions correct?

Hi Maarten,

Thanks for getting in touch! You can get the retention policy task to run now by finding a previous task and selecting Re-run this task from the top - its a cheat way to force it to run when ever you wish.
As for the explanation, packages do work differently to retention on server and in the Lifecycle. Once a release is deleted all used packages for that release should be deleted on the next run of the retention policy.
For undeployed packages, they will be kept for the time you state in the Library -> Packages retention policy which you state is one day.
The undeployed packages should be deleted after a day of not being released. It will not matter how many releases and packages come and go within that time if they have not been deployed yet and their releases still exist.

You are welcome to send in your retention policy logs and screenshots of the packages directory if you like so I can confirm it is working as expected.
The tl;dr is that the Lifecycle retention policy only effects the package retention policy based on the server setting and when it deletes the releases, otherwise the package retention policy works fairly independently.

Hi Vanessa,

Thanks for you response.

Well it’s probably because I don’t fully understand how it all works, because if it was really broken, my package folder was went through the roof already. So hopefully you can help me to connect the dots. Some things that I don’t understand:

  1. I have stated that I want to keep 3 production releases. Does it mean that it saves the current release + 3 previous releases, or 3 in total? It seems to do the first.
  2. I have stated that I want to keep 1 test and 1 development release. Currently it has 3 of both. If we apply the logic in question 1, 2 releases will be the max. So where is the third release coming from.

Where can I find the retention logs?

Hi Maarten,

We explain a little about what is kept here: https://octopus.com/docs/administration/retention-policies

  1. You are correct we keep the current release plus the number specified. It is based on the fact that if you wanted to keep 1 release, by also having the current release you have something to roll back to if needed.
  2. If either of those have been deployed to production then they will now be using the production phase, if they have not yet gone to production then those releases should be at max 2.

You can grab the retention logs in the same way as a task log: https://octopus.com/docs/how-to/get-the-raw-output-from-a-task
You can go to the tasks page, select retention as the type, and find a retention task, then grab the log as described in that page.