What is a good approach to saving packages on promote?

The design that I have is a CI server that builds deployment packages, uploads to a NuGet server, then deploys to the CI environment in Octopus (from the external NuGet server). This all works great. However, it leads to a serious accumulation of packages (from the CI builds). I have the ability in my NuGet server (ProGet) to clean up package feeds, but I want to make sure that I don’t delete a package that has been promoted from CI (so I can always redeploy a promoted environment). What I am trying to figure out is the best way to do this. I have a couple of ideas.

The first is to have a step that only executes in the promoted environment that uploads the package to a second feed (one that doesn’t get cleaned up). This works, but it makes everything more complex, as there are now multiple feeds.

The second is to make the CI packages experimental (in terms of NuGet version) and on promotion change the version to a regular version. The cleanup task then only removes experimental versions.

My first question is: do I need to do this? Is there some way that I can configure Octopus to keep promoted packages locally, so even if they disappear from the source, I can still deploy them. If not, any thoughts on how to handle this situation?


Hi Erick,

Thanks for the questions.

You will need to keep your packages in a NuGet feed if you want to deploy them in future. We do something similar to your second option: changing the version of experimental packages to a regular version. When there is a build that we are happy to promote out of CI we actually tag is as “OK” in git and then it re-builds into a package without a special version. Using this method we can apply a different lifecycle to CI builds than to “promoted” builds so that CI builds can never ever end up in production.

Using this method you could also let Octopus handle NuGet retention by using the built-in Octopus NuGet feed and applying a tight retention policy on your CI releases. Octopus will keep any packages that are referenced by a release so your promoted packages will be kept forever and the CI packages deleted as soon as the CI release is cleaned up.

Hope this helps.


Thanks Shane - I really like that approach. We’re using ProGet, which has the ability to clean up old packages based on the tag, which fits this scenario perfectly.