Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Retention Policy - Ability to have policy run per group (e.g. Application)
-
Hi Buildmaster,
Years ago when I was setting up BuildMaster for another company I made a huge mistake with retention policies. The documentation doesn't really state one way or another (and still doesn't) but I thought when you specified how many releases to keep that since releases were per Application it would be how many per application that the policy applied too. Turns out this was far from the truth. My policy applied to all my applications and when I set it to keep at least 5 releases or at least 3 months worth it mean 5 total through the entire build master. OOPS!!!Now that I'm attempting to set it up again at a new company I was curious what improvements were made with the latest version and it doesn't appear much has been done with retention policies since I last looked at it. I'm curious if I can put in a request for a new feature. After reading your instructions and thinking about the screen I can see why it would work the way it does but it also occurred to me there might be a way to add a feature to make them easier to maintain and work more like I was originally thinking.
Could you add a feature for the retention options where you could pick the level to apply it. If you left it unrestricted (which could be the default) it would work like it does now. But you could also specify it to run at the Application level so it would execute the retention policy per application it applies too. This would greatly reduce the amount of policies that one would have to keep up with and therefore reduce errors in setting it up and keeping it consistent across applications. Not sure if there is an official place for that feature requests but I thought I'd stop here.
Thank you,
Brandon -
I'm afraid we have no plans to touch the (current) retention policies code. It's very sensitive -- and it has quite a few quirks -- but it does work fine once you know how to use it.
At some point, we would like to just rebuild the feature from the ground-up and introduce it as a side-by-side feature. But that's quite an effort and it's not our roadmap at this time I'm afraid.
--Dean
-
Hi @dean-houston,
If nothing else could you at least update the documentation. I complained about this 6 years ago after wiping out nearly all my production builds. I think you should have a warning about the fact that the conditions are not app specific when it talking about the last N item.
Also, I never asked for a timeline, just the ability to add something for consideration in the future. A lot of companies have a place where you can make a request and even have customers vote on it so they can see the interest before considering it. I just wanted the chance to have it recorded somewhere so it could be considered when you got around to it.
Thank you,
Brandon -
We can certainly update the documentation; what would you suggest to change?
Feel free to submit a pull request as well :)
As for how we handle feature requests, it either gets "added to our roadmap" or not. If not, then it just stays "in the ether" until it comes up again.
When it comes time to plan for a release (e.g. BuildMaster 2027), we choose from items from that roadmap (it's an internal checklist) or shift them to next year.
After a few shifts, we remove it from the list and goes back "to the ether". Redoing Retention Policies in BuildMaster were on the roadmap for an extremely long time, but there are just so many areas of improvement that kept coming up instead. And that's why it's not on our roadmap now.
The forums are a great way for users to vote or share ideas, so this someone can always reply to this post in the future.
-- Dean
-
Hi @dean-houston,
Thank you for such a quick reply. I guess I didn't see this post as "getting it in the ether" as you would say. Maybe I was wrong about that. Certainly didn't seem to happen with the support ticket 6ish years ago, but that could be the difference been using paid support vs the open forum.As far as the documentation goes I can put up an attempt at what it could say, but I'd totally expect it to be edited if it were to be used. The blow can be put as a caution or warning block instead of part of the normal documentation.
When using the Count feature please note that it does not count per application. If you have a retention policy that is not restricted by app you can end up purging all releases for certain apps. You may want creating a retention policy for every app if you intend using this feature.I will consider looking at the code as well and coming with a suggestion for the implementation of the enhancement I have in mind.
Thank you,
Brandon -
Hi @dean-houston,
I totally misunderstood what you wanted to the pull request for (I should have looked at the link closer). I did create one though. I made a few corrections to what I put in this post.
Thank you,
Brandon -
@brandon_owensby_2976 fantastic!!
Thanks much; I'll let our technical writing team review/accept it, They should within a day or so
-- Dean
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login