I would have expected packages to be deleted once I manually deleted a release, but they were not.
Why?
Hi Michael,
Package clean-up is managed via Retention Policies. See the section in the linked document on 'NuGet feed retention policy".
I hope this helps.
Michael R
Thanks. I’ve reviewed this, but it’s not easy to follow.
If I delete a release manually, is it possible to configure a policy that will automatically delete the corresponding packages?
Yes. If you navigate to Library -> Packages on the right-hand side you can modify the retention-policy for packages that are not included in any release. The minimum value you can supply is one day. This means the packages that are orphaned when you delete your release will deleted the following day.
The reason there is a one day minimum is, you may push a new package, and not have created a release for it yet. If there was no minimum clean-up time, these packages would be immediately removed, before a release could be created. Alternatively, you may delete your release and be planning to create a new release for the same package. Again, if there was no minimum time, the package would be immediately removed.
I hope this helps!
Michael
This is helpful in terms of understanding the situation.
However, there should be an option to immediately release packages associated with an already-deployed release. This should appear on the “edit release page” and there s/b a checkbox near the Delete button with the text “Delete packages included in this release” (unchecked by default).
Hoping the developers can consider such an option.
Can I ask why this option would be preferable to the current approach? So long as you know the packages will be cleaned up, does it matter if it’s not immediate?
Actually, it does matter that it’s not immediate. The scenario is that we have deployed a release, for example 1.2.3. This is not our normal deployment process, but occasionally we want to completely replace 1.2.3 with a new release – with the same version number. Therefore, we need to delete the release and all associated packages so that we can deploy 1.2.3 again.
In that situation, once you have re-pushed the package to the NuGet server, when you next trigger a deployment there is an option on the create-deployment page (under ‘Advanced’) to 'Re-download packages from the NuGet server`. This will ensure your cached packages are not used.
I hope that helps!
Your latest idea won’t work.
We are deploying from the command line, and the command line throws a fatal error if we try to push the save package version.
Hence the need to delete a release AND have the packages associated with that release deleted.
Ahh, I see.
Originally the built-in Octopus NuGet repository would allow you to push the same version of a package. This behavior was changed a while back.
All I can suggest then is to delete the package/s when you delete the release. This can be done via the UI or the REST API (with a HTTP DELETE to api/packages/{package-id}). Or, for these occasions, to do something on your build server to build the package with a build component in the version number?
Could these options work?
Hi Michael,
An update for you on this issue:
As of version 3.2.4, you are able to push to the built-in Octopus NuGet repository and overwrite an existing version of a package:
http://docs.octopusdeploy.com/display/OD/Push+a+NuGet+package+that+already+exists
I though this might be of interest to you.
Excellent news and thanks for the update. Is 3.2.4 out yet?
Not as of this moment. It will be in the next couple of days.