Is there a way to set up a retention policy that deletes the packages but keeps the data?
For auditing purposes, we need to keep the release data - e.g., when the deploy was made, to where, any failures / retries, etc. However, we would like like to be able to delete the associated packages to conserve space. We are using team city for builds and integrating with Octopus, so we have the required data to recreate the packages well enough for an audit if needed.
Using the current retention policy features, it looks like we can only automatically delete packages after the releases are removed - is there a way to automatically remove the packages and keep the releases?
Thanks a ton!
Thanks for getting in touch! Just so i’m clear because we have packages in multiple places and multiple retention policy settings. Which packages are you finding building up too quickly?
Based on your wording can I assume you mean the ones that the Octopus Server pulls down for a deployment and then sends to the Tentacles?
How many of these packages would you have on average in a week?
We are using the Ocopus nuget repository to store packages. Those are the ones we want to delete without deleting associated releases that have been deployed at some point.
Jeff Hewitt | Credera
972.839.8155 | email@example.com:firstname.lastname@example.org
Thanks for the clarification. No the retention policy really has its hands tightly around packages that are associated with releases.
You will have to manually delete them or setup a script to do so. If you want to manually delete them from the folder, you can do this, and then restart the service to rebuild the package index.