Same issue as this but I don’t feel as if this is resolved.
I am having the same issue.
My retention was originally set to 30 days, but now I would like to trim my releases to a low number (3 or 4)
I realise that this might leave some releases over 30 days, but certainly not in our fast moving development channel(s).
No matter what value I enter in the UI for number of releases to keep in the Lifecycle, the same error is shown.
If this is supposedly intended behaviour, then what is the point of even having a “Number of Releases” option?!
We also can no longer select the “Keep All” option for releases. Not that we want to use that, but it adds to the impression of something being broken.
This does still feel broken to me and it’d be good to get an answer on how to set our retention policy to number of releases for a lifecycle.
With our Cloud instances, it currently is not possible to use the ‘Releases’ option when setting a Lifecycle retention policy. It must be set using Days and be lower than 30.
We understand that it is confusing that the option exists but can’t be used, this is due to the fact that it can be used for an on-premise install of Octopus.
We are looking at the best way of tidying this up for Cloud instances that doesn’t require us to manage a separate code base for on-premise and Cloud.
An ideal situation for our lifecycles would be to have a short retention of a couple of Alpha releases for us as these change rapidly, but at the same time it’s be great to hold a few more (or all) releases of our stable as this doesn’t update frequently at all.
At the moment this is becoming very difficult to manage with our storage limit constantly being reached and blocking our CD pipeline.
We believe that we could manage our releases and therefore package lifecycle and storage a lot better and still use the “Number of Releases” option. It feels as if this change to 30 days max retention is a bit of a blunt instrument to solve a more nuanced problem of your storage.
We accept that the storage limit on the Cloud account is needed. You need to prevent abuse. We can work within that.
But taking away vital controls at the same time that would help users manage that limit I think is a bad decision.
Is there anyone at Octopus we can speak to to perhaps get this enabled?
We’re happy to discuss payment. It would be good to increase our storage limit too a little, but at the moment this retention issue is beginning to cause a major issue for us. It’s blocking up our CD pipeline and while deleting packages is reasonably fast, manually removing releases from all of our deployments is causing a headache and that would solve a lot more of the problems in the long run.
This change is still being discussed internally as there have been a small number of customers that when setting the policy to retain only 1 days worth of releases, have actually seen an increase in the space being used due to the number of releases they generate within a single day.
Is your situation similar to this, is there a significant number of releases being created within a single day?
The release retention will never remove a release that is still visible on the dashboard. So, you can try reducing the number of days that a release is retained without worrying about currently active releases being removed.
For example, if you set the retention for your alpha releases to 1 day, even if you go several days without creating a new release, there should still be a couple of releases retained as these are the ones on the dashboard.
The limits that we’re putting in place to manage the instance storage isn’t about cost for us, it is about time. As an instance grows in size, the downtime required to perform larger tasks such as moving the instance to a new reef increases making it impossible to carry it out within the current maintenance windows.
If even after reducing the number of days that releases are retained, it still becomes impossible to remain within the storage limits, then the other option would be to look at an external package feed. There are options such as feedz.io and MyGet that can easily integrate with Octopus and would remove the retention issue entirely.
Yeah we are exactly in that situation. In the middle of development we might have only one or two alpha deploys every few days, but in the lead up to release or for a number of small fast features we might have multiple alpha builds an hour. It’s all running automatically from our commits and PR merges and we use it to perform CD testing for every commit.
It’s good to know about the dashboard quirk. We might have to use that to our advantage. I’ll look to reduce retention to 1 day for now.
Like I said, the storage amount isn’t so much of an issue. I think we can get back under our limit relatively easily. I think it’s just a shame we can’t continue to use the “Number of Releases” option. Everything you’ve said above still only really answers the storage issue but not why the available retention policies have been changed. A 10Mb package that is 2 days old or 200 days old is still only 10Mb. Either that or I am misunderstanding something.
Therefore I would still counter that allowing more control over releases and package retention would allow us to manage our storage properly, and so allow you to be able to move instances around and perform whatever maintenance you need.
I don’t disagree with you, and I have passed your feedback to the relevant parties internally to add to the list of other customers that are finding this change too restrictive.
Hopefully, it is something that will be changed down the line.