Repository Cleanup with Variable Package Names (part 2)

This discussion is in reference to a previous closed topic:

I have the same exact issue laid out in the linked topic - I have Step Templates that “standardize” certain deployment steps. These Step Templates take Parameters that fill in several Step fields; one of them being the Package ID. See screenshot below.

Step Template Screenshot

So, the explanation in the linked thread above makes sense. I get why it’s not possible to implement cleanup within the current process, however…

What about including the option to “force cleanup packages”? There are two options that I think are viable:

  1. This one will likely break less things less often - only X most recent versions of packages are maintained, regardless of whether it has been used or not.
  2. This one may break things more often, but - package versions get cleaned up past a certain age, also regardless of whether it has been used or not.

What do you guys think? Doable?

The reason I am bringing it up is because we have been using OD for about two years now with over 50 machines and package versions being generated anywhere from multiple times a day to once every two days. Disk space on our OD server is filling up constantly and we have to go in and manually delete packages from within the OD interface every few months. This is turning out to not be too productive.

Any help in solving this issue would be greatly appreciated.

Hi Jesse,

Thanks for getting in touch! What version are you using? In 3.4.12 a change was made to clean up packages used in step templates:
It will only work if you define a direct value for the package ID on use and not use another variable.

Give it a go and keep me updated.

Hi Vanessa - thanks for the quick reply.

Unfortunately we use variables to specify the Package name at the project level as well. This completely exempts our setup from any package cleanup.

Are there any alternatives?


Hi Jesse,

The issue is we don’t know what packages you are going to need at deployment time as variable scoping and evaluation is only determined at a step running time, so we cannot determine what packages you would need thus know what is safe to delete.

I have seen customers implement their own tasks and cleanups of the directory with the methods that you mentioned originally via scripting. I don’t know if I have seen any examples. If you determine you want to setup your own cleanup and run into issues we can try to help.
Currently I would say it’s unlikely we would implement anything baked into Octopus for that purpose - maybe UserVoice is the way to go?


Hi Vanessa - I understand.

From a cleanup perspective - if I delete the files manually (in explorer), will anything break within Octopus Deploy? I’m thinking indices, database records, etc.

Hi Jesse,

Nothing will break, but the repository will still think the files exist until it is re-indexed. This happens on service start up or can be triggered by the Library -> Packages screen.
I have a PowerShell script that will re-run an existing task if you want to automate that. Let me know.


Vanessa - I’d like a copy of that PowerShell script to re-index the Packages.

Hi Jesse,

This script relies on an existing sync task - when you run the task via the button in the UI the ServerTasks ID will be in the URL.

# You can this dll from your Octopus Server/Tentacle installation directory or from
Add-Type -Path 'C:\PathTo\Octopus.Client.dll'
$apikey = 'API-1234' # Get this from your profile
$octopusURI = 'https://blerg' # Your Octopus Server address

$endpoint = New-Object Octopus.Client.OctopusServerEndpoint($octopusURI, $ApiKey)
$repository = New-Object Octopus.Client.OctopusRepository($endpoint)

$taskId = "ServerTasks-132727" # Get this from /api/tasks

$task = $repository.Tasks.Get($taskId)