search

OctopusDeploy / Issues

| Public | Bug reports and known issues for Octopus Deploy and all related tools
https://octopus.com
162 stars 20 forks source link

Retention policies for built-in NuGet repository #636

Closed PaulStovell closed 10 years ago

PaulStovell commented 10 years ago

Extend the retention policies to allow users to choose how long to keep packages in the built-in NuGet repository. Example:

Keep the last 12 versions of each package

Then modify the retention policy cleanup task to delete the old packages.

jstangroome commented 10 years ago

Presumably a package progressing through a deployment pipeline should not be subjected to the cleanup task.

nblumhardt commented 10 years ago

A package used in a successful deployment, or a production one, should also outlive a package only used in failed builds or only deployed to development. The v - 1 package just retired from production shouldn't be deleted just because there have been 20 nightlies pushed from CI.

Seems like there should be a smart way to manage this.

PaulStovell commented 10 years ago

UserVoice item: https://octopusdeploy.uservoice.com/admin/forums/170787-general/suggestions/5599134-add-retention-policies-to-internal-nuget-server

nblumhardt commented 10 years ago

I've jotted some ideas in https://github.com/OctopusDeploy/Issues/issues/689#issuecomment-39796466 for how we can do whitelist-based retention on Tentacles.

For the built in feed I think we should use the same mechanism: work out which package versions are used in active deployments or releases, and delete everything else.

The twist would be that we'd also specify a "nursery time" during which a recently pushed package would be left in the feed regardless of whether deployments/releases exist for it.

nblumhardt commented 10 years ago

Despite changing direction on #689 I think that's the basic direction we should take for this ticket.

The scenario to watch is going to be when a CI server pushes many versions of a package, but only some get used in releases.

The algorithm seems a bit simpler:

  1. Packages are deleted when the last release referencing them is deleted
  2. Packages are given X days from arrival to be included in a release, and if they're not when that time elapses they're deleted

One outstanding question is whether it makes sense to delete packages that are still referenced by releases under any circumstances. It seems reasonable from some angles, but keeping a record of a release yet throwing away arguably the most important part (the deployable packages) doesn't really make sense.

lock[bot] commented 5 years ago

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.