One of the items on our backlog is the ability to set a retention policy for projects, which automatically cleans up old deployed applications, cached NuGet packages, and releases/deployments from the Octopus UI.
This item isn’t done yet, but in the mean time, if you need to delete releases/deployments, you can now do it using the latest version of Octo.exe along with an Octopus server running version 1.0.31 or higher.
From the command line, the syntax is:
octo delete-releases --project=MyProject --minversion=1.0.0 --maxversion=2.0.0 --apikey=ABCDEF... --server=http://<your-octopus>The version numbers are inclusive, and can be partially specified - e.g., 2.0.0 or 2.0.1982.12981. SemVer rules are used when comparing the version numbers.
As I said, this isn’t enough to be a full retention policy feature, but it might useful if, for example, you accidentally created a few hundred releases because of a circular dependency in your build/deploy scripts.
Tags:
Related posts
Configuration Management with Octopus and PowerShell DSC
At Octopus Deploy we keep rattling on about how Octopus is API first. One of the benefits of being API first is that you can do anything that the Octopus UI does via web requests.
Tenant aware lifecycles
Let's take a look at how the inclusion of tenants influences the deployment Lifecycle process.
The Power of Configuration Transformations
It is a common scenario to perform different configuration transforms depending on the Environment that is being deploying to.
