Different Package Retention Policies for Built-In Package Repository

[ChrisUsher]

Hi,

We are using Octopus Deploy both for “UAT” deployment projects and also for “CI” deployment projects.

We are using the built-in package repository to store packages.

UAT projects only push packages to the Repository once a month or so, CI projects push on every commit.

How do I prevent the CI project from filling the Octopus Server disk and preventing further uploads of UAT packages which are more important to the Octopus Package repository? I want this task to be done automatically without having to set myself a reminder to delete old CI packages month.

I have set the Retention Policy on the Lifecycle but this did not remove any packages from the Built-In Package Repository.

I do not want to use the global retention policy in the Package Repository, as I have lots of unassociated release packages that could be used at any time in the future.

Thanks in advance,

[Michael_Compton]

Hi,

Thanks for getting in touch.

It sounds like what you are after is different retention policies for different packages, which Octopus doesn’t support.

I think the best answer is to use an external feed to push the CI packages to. Your CI project can then download from the feed for each deployment it does. You would then also be able to configure a retention policy for that feed independent to the Octopus built in feed.

We’ve been using https://feedz.io/ (which was developed independently by an Octopus team member - the quick indexing time and Octopus integration work nicely for us), but any NuGet feed like MyGet and Artifactory would work great.

The docs for setting up a feed that works for you are here.

Michael