Shane Gill on 13 Oct, 2017 12:19 AM
Thanks for getting in touch. I'm sorry to hear you release has gone missing.
It may have been cleaned up by retention (https://octopus.com/docs/administration/retention-policies). Retention policies are set by lifecycle, you can find the retention policy for a project by going to the project page and selecting "Process". The lifecycle is shown on the right. Take note of the lifecycle and then head to Library > Lifecycles. Click the lifecycle appropriate to your project and the retention policy for that lifecycle will be shown.
If the lifecycle is set to keep a limited number of releases, my guess is that your release was cleaned up. If that is the case, there is no way to recover the release except to restore a database backup.
I’ve checked the lifecycle and it is limited to keep 5 releases. However, in the project page, under “Releases” , I can see many releases also the previous ones. I mean, missing release is v0.0.1348 but for example v0.0.1294 is there although it is a previous release. Do you have any idea about this?
Shane Gill on 13 Oct, 2017 07:00 AM
Retention policy for releases is based on lifecycle phases. When retention is set to keep 5 releases, it will keep 5 releases for that phase. That means you could have 5 releases for Production, 5 releases for Test and 5 undeployed releases. If you had 5 undeployed releases and created a new release, the oldest undeployed releases would get cleaned up by retention.
The retention task provides a fairly detailed explanation about why releases are kept or deleted. You can find it by going to the "Tasks" page, using the task type drop down filter to select "Retention" and then clicking on one of the tasks. The verbose log will contain the reason why some releases are kept and others deleted.
From the screenshot of the dashboard that you sent I can see 1581, 1533 and 1508 are in the "Production" phase. Only two more releases will be kept in "Production", so I am guessing you have two releases that were deployed to production after 1348.
Shane Gill on 18 Oct, 2017 10:14 PM
I'm glad to hear you upgraded. Unfortunately the audit events will only start appearing for deletions that occur after the upgrade, they were not being created for retention deletions before the upgrade.
They won't be able to help you find 0.0.1348 but this should never happen again - every release deletion will have an audit entry.
1.) If we set the policy to keep all releases, does it cause any performance/other issue?
2.) In the screenshot on previous mails, there is a release (0.0.1294) deployed before 0.0.1348 but still exists in Octopus. We really want to know how it happens. If the policy is set to keep 5 releases, the last 5 should have been there. We’re really confused.
Shane Gill on 25 Oct, 2017 10:33 PM
1) Keeping all releases can cause performance issues if you are doing a lot of releases. You might want to keep all production releases?
2) Release 0.0.1294 was kept because it is in the UAT phase. Your retention policy is set to keep 5 releases in UAT and 5 releases in Production. Because 0.0.1348 was deployed to Production it was deleted because 5 other releases were deployed to Production. Once a release is deployed to the Production phase it is not longer in the UAT phase, so doesn't count towards UAT retention.
Here's an example, keeping 5 releases in UAT and 5 in Production:
0.1 -> UAT
0.2 -> UAT -> Production
0.3 -> UAT -> Production
0.4 -> UAT -> Production
0.5 -> UAT
0.6 -> UAT -> Production
0.7 -> UAT -> Production
0.8 -> UAT -> Production
The releases currently in the Production phase are: 0.2, 0.3, 0.4, 0.6, 0.7, 0.8
The releases currently in the UAT phase are: 0.1, 0.5
When retention runs it will only delete the release 0.2 because it is the 6th deployed release to the Production phase (only 5 will be kept). None of the releases from UAT will be deleted because there are only two releases in that phase. 0.1 is kept even though it is older than 0.2 because of the phase it is in.
1. Actually yes we were thinking to keep all releases but if it can cause performance issues, we won’t. Instead of all, what is the limit to not
lose performance? For example 20 releases or 30 releases?