Release retention policies

Hi all,

I’m in trouble with release retention policies.
Here my scenario.

Project_A has two channels: Channel_Test, Channel_Prod (default channel)

Channel_Test adopts Lifecycle_Test
Channel_Prod adopts Lifecycle_Prod

Lifecycle_Test has 3 environments: Test (mandatory), UAT (optional), Staging (optional)
Lifecycle_Prod has 1 environment: Production (mandatory)

Every lifecycles has the following retention policy
Releases: Keep 5 releases. Files on Tentacle: Keep 5 releases.

In Channel_Test I deploy releases often in Test environment only.

In some cases the retention policies works fine (most of time in Channel_Prod with only one mandatory environment) otherwise octopus keeps infinite releases (and also infinite packages).

It could be possible Octopus couldn’t delete releases (and packages) whose do not have all environments (also marked as optional) deployed?

Thank you!

Hi @fabrizio.mancin,

Thank you for contacting Octopus Support. I’m sorry you are having trouble with this.

I hope you don’t mind, I have a few requests to hopefully get a better handle on what is going on this situation. Could you provide the following?:

  • A raw task log of a recent “Apply retention policies” task
  • A screenshot of the Dashboard (aka, the Project “Overview” page) of an example Project having retention issues
  • JSON of the lifecycles associated with the channels used in the project.

To generate the JSON for your lifecycles, do the following:
Navigate to Library -> Lifecycles -> click a lifecycle

Change the URL in the address bar as such:
http://localhost:8000/app#/Spaces-1/library/lifecycles/Lifecycles-2?activeTab=details -> http://localhost:8000/api/Spaces-1/lifecycles/Lifecycles-2



You may upload this via this secure link.

Let me know if you have any trouble. I look forward to hearing back from you and helping you get this sorted out.


Hi @donny.bell

I’ve uploaded the files as requested.

Thank you

Hi @fabrizio.mancin,

Thank you for providing that.

Apologies for any confusion, the “Apply retention policies” task I was referring to is a stand-alone task. You can find these under Tasks -> Show Advanced Filters -> select “Apply retention policies” in “By task type”. If you wouldn’t mind sending a recent raw task log of one of these tasks, this should give me most (if not all) of the information I’ll need to see what is going on.

I look forward to your response.


Hi @donny.bell,

I’ve uploaded ServerTasks-36383.log.txt.

Sorry for the mistaken log file.

Thank you.

Hi @fabrizio.mancin,

No worries. Thank you for getting back to me so quickly.

I appreciate your patience while I review this.


Hi @fabrizio.mancin,

Thank you for your patience.

I have reviewed the logs and don’t see anything too out of the ordinary. There are a few instances of older releases remaining on the dashboard such as these:

16:28:01 Info | *Line 47* - Release 3.11.11 is the previous release for a release on the dashboard, so it will be kept to allow rollback

16:28:01 Info | *Line 257* - Release 20.12.21-beta.1752 is the previous release for a release on the dashboard, so it will be kept to allow rollback

16:28:02 Info | *Line 300* - Release 20.12.21-beta.1755 is on the dashboard, so it will be kept

Releases that appear on the dashboard will cause the retention policies to count back from that release, even if it is effectively “old”.

Perhaps, are you finding the packages on-disk in the built-in feed are not getting deleted as expected?

Let me know at your earliest convenience.


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