The explanation makes sense but it seems that cleanup on internal nuget packages is not supported when they are referenced via variable names. Is there a suggest work around?
To shine more light on our workflow and why we use nuget packages with variable names we have the following structure in a lot of our projects:
Create a step template to deploy a web site and perform setup common to all of our apps
Define variables as parameters to step template, including nuget package name
Use step template across a lot of projects plugging in the Nuget package ID directly (not via a project variable)
Could you offer a workaround for cleaning up nuget packages in this scenario? Also, since the Nuget packages are actually hardcoded in to the step template parameters then shouldn’t Octopus be able to figure out which packages need to be cleaned up?
Thanks for getting in touch. Unfortunately, step templates with a package ID parameter still fall into the same category as the ones described in that help thread. The best workaround is to write a script (Powershell or other) to run periodically as a scheduled task on your server to clean up the packages. This gives you full control and you can delete packages to suite your needs (date, version or both).
If you think we should revisit this, I’d recommend adding a suggestion to our user voice site at http://octopusdeploy.uservoice.com/. If other customers agree, it’s likely we’ll look into this further in the future.
I understand that it falls in to the same category and unfortunately expected powershell as the suggested workaround. My nuget package is a hardcoded value in the step template parameter so shouldn’t resolving this in the cleanup task be a pretty simple lookup? I am surprised this doesn’t affect more users because I would have expected this to be a fairly common usage pattern. My workaround question was more geared towards this…are there any out-of-the-box workarounds that you would suggest (i.e. set up my steps differently and somehow extract the nuget part from my step template) that don’t involve custom scripting? I would like to leverage the built-in features of Octopus wherever possible.
Thanks for the reply and additional details. Under the hood, the step template still uses bound variables so we’re face the same challenge resolving them. I’ll note that we do have one open issue which may improve this in the future (it’ll be determined when we make the change). You can review the issue at the following URL.
The best way to workaround this issue using out-of-the-box features would be to do something the following.
Put common initialisation in Library script modules and common variables in Library variable sets.
In your projects, use package steps with un-bound package IDs and add additional script steps to use the common variables and script modules.
The main trade-off with this approach is that there would some duplication to execute the common setup code.