Package Repository Retention can be too brutal

When using the Octopus Deploy NuGet package repository, it makes sense to have a retention policy in place to remove old packages.

However the current option can be a little too brutal (as we discovered after the Christmas & New Year period…) if you want to deploy the latest build of a project, but one which was build longer ago than your retention policy period.

Could the retention policy be changed to give the option of keeping a certain number of packages?

Hi Richard,

Thanks for the feedback! The retention policy will not delete any packages that are part of a release, how often do you push packages up that aren’t used for a while (or at all?).


Hi Vanessa,

We are using TeamCity as our CI builder, and it runs a build on every Git commit, out of which we get an OctoPack package which will be pushed to the Octopus Deploy NuGet server.

This means that we have lots and lots of packages, only a small number of which get used in a release.

In general, we would always want to keep the most recent package (regardless of whether it has been released yet) since a period of time can elapse between Git commit and a release of the package that was built following that Git commit.

Does that explanation make good sense…?

Hi Richard,

Thanks for the reply, it does make sense. Currently you can only specify the unreleased packages to keep by days, but when working on 3.0 I’ll see if we can make it keep a specific number of items instead.


Hi Paul,

That’s great, I’ll keep my fingers crossed that this makes it into one of the 3.0 released.