Expand retention policy to be version based

Currently if you setup a retention policy to be based off 3 items, it will delete folders past the 3 items back. In our scenerio we have version numbers in our Nuget packages and in Octopus of WCF services that are hosted in IIS. We found that when Octopus retention policy ends up deleting a folder that is being pointed to by IIS that IIS will then just fails to load the application pool and crash everything else in that same application pool. To address this, can the retention policy be enhanced to support versioning and especially in relation to the tentacle policy? All of our release numbers are in format .... so for example say you already had these releases:

1.0.0.0
1.0.0.1
1.0.0.2
1.0.0.3
1.1.0.0
1.1.0.1
1.1.0.2
1.1.0.3

let say 1.2.0.0 gets released. if we based retention policy on major/ minor version, then 1.0.0.3 and 1.1.0.3 would get deleted if we assume we wanted to keep 3 items for each major/minor version. Which parts of the version number are used to determine what retention is based on could be configurable.

Thanks for reporting this Kirk. I’ve noted the issue here:

Regards,

Paul Stovell
Octopus Deploy
W: octopusdeploy.com | T: @octopusdeploy http://twitter.com/octopusdeploy

I realized recently that I kinda forgot about this issue and was not subscribed to the thread on github. I went through those results, but Im not sure what happened with this. Was this ever addressed and if so how does this work in v2.5.x? the github thread mentioned something about a new variable, but I cannot find any documentation on it’s use. Is there a way to accomplish version specific retention yet?

Done - the special variable is called Octopus.Tentacle.CurrentDeployment.RetentionPolicySubset .

fyi, that last sentence about the special variable was cut/pasted from the github thread to show what I saw.

Hi Kirk,

We made a few changes:

  • We figure out which packages should be kept/deleted based on the action/step ID, not the package ID anymore. So if you have three projects, A, B and C which all use the same package but different versions, they won’t affect each other
  • I believe you can create your own variable named “Octopus.Tentacle.CurrentDeployment.RetentionPolicySubset” and set it to different values per release/whatever. This will be used to create unique groups of packages to be retained individually. E.g., in your original example, the values could be “1.0”, “1.1” and “1.2” to ensure the last 3 of each patch of the major/minor versions are kept.

Hope this helps!

Paul