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 Policies for PR Builds
-
Buildmaster,
In another post I asked about the best way to set up builds off PRs (mainly for the purpose of verifying they build before allowing them to be merged). The result of that ticket was that the build would be created without a release if it was generated off a PR. The regular builds would be done on a release as usual. This solves the one issue I was going for which is to make it clear what type of build one was if you were looking at it but it doesn't solve the clean up.I realize I could set up a build specific retention policy but in this case there isn't really any options that make sense. Once the PR and/or branch is gone there isn't really a point to keeping the build around any longer. In my opinion these PRs/Branches should be short lived and so should the builds but my company (at least at this time) may not run things in a way that would make that true which makes the cleanup that much more important to get right.
You have a the ability to define scheduled tasks and I thought this would be a great way to write a custom cleanup script. Unfortunately when you run a script from the scheduled tasks that doesn't run in the context of a release/build it becomes quite difficult to interact with the system on the release/build's behalf.
I'm curious (since I'm a .NET developer) if the best option would be to write an extension in this case. I'm currently reading documentation on that. I also played around with making rest calls to buildmaster but I have to admit it seems odd to make calls from buildmaster to exit buildmaster and come back externally to get information to use within buildmaster. Even sounds confusion when you write out
. If I were to write an extension it would probably be a repository monitor as that would likely be the most efficient way to handle it. I actually originally thought I could the repository monitor feature that was built in but it doesn't have an option to monitor when PRs are merged/deleted. Hopefully that is something I can figure out how to write in an extension.If you have other thoughts I'd appreciate it.
Thank you,
Brandon -
This post is deleted! -
While it's technically possible to create a custom repository monitor (see the Subversion one), I'm not sure if I'd recommend it for this use case.
Did you see our guidance here on build clean-up?
In a feature branch pipeline, a build should still be promoted to a final stage ("merged" or something), and once that happens it's status can be set to Rejected. So, instead of worrying about whether the PR is merged/deleted, just delete rejected builds after X days.
-- Dean
-
@brandon_owensby_2976 I definitely do not recommend it, but if you are intent on creating something that automatically promotes feature branch builds to a "rejected" stage, you could code a custom PromotionRequirements.
You'd be much better doing something on the GitHub side that promotes a build using the API, however.
-
Hi @dean-houston,
I appreciate the info and that is actually an interesting idea. If certain things were different I might actually consider something like that too. Since I'm trying to sale your software I have to consider the customer and the fact that some part of the company might be looking for any reason to reject the software. I'm sure you can understand how change is often perceived. Even though I don't totally agree with our current process I need to show the ability to support it so they can know the software can be used without being "forced" to change their process right up front but I also plan on showing how the software could be used to improve the process as well which might eventually lead in some change.One big reason for the clean up is to keep there from being clutter making the system harder to use as well as take up more space. For your idea to work well I'd have to try and set it to a number of days that would keep the builds from being deleted too quickly but this would increase unnecessary clutter as it would force you to keep builds you don't need longer than necessary. The PR is a built in life cycle so why try to fake it with an arbitrary number of days, it doesn't make any sense from a design perspective. It allows you to have the minimum amount of stored builds necessary for what is going on. Only the odd ball PRs that are held up will have it's builds stick around longer.
When I mentioned about them rejecting your software it is because the current software already handles it. It creates the build when a PR is created or modified (which yours does to) but also deletes the build once the PR is deleted or merged. I'd hate for you (or me) to lose out on something so silly so it is worth the extra effort for me to make it work.
On the note of the repository monitor, I thought that seemed like a great idea as you already have that for creating builds so it seemed like you did 90+% of the work for having it clean them up as well. I started to build my own but went a different approach for one reason. If you only listen to when one is removed there are scenarios where the cleanup wouldn't happen. So instead I created a custom operation that can be run without app context that loops through all the apps and finds all the builds without a release and determines if the build was done on a branch that no longer has an open PR and purges it. I then created a scheduled task in BM to run this every 5 minutes. This makes the clean up it pretty much instantaneous and makes your software competitive with our current solution.
For the record, for any other users reading this post, I originally tried this same idea using just an otter script. If you were to set up a scheduled task for every app it makes it easier but that would a lot for us to maintain and set up due to the number of apps we have. For that reason I wanted the script to run for all apps we have configured. I had an otterscript (in conjunction with a few powershell scripts) that was nearly fully functional but it was getting a bit complicated running without an app context. It was easier to do with a custom operation but it does mean having a library I have to keep with out side of BM.
Sorry this was so long but wanted to include detail for anyone researching the same thing I was.
Thank you,
Brandon -
Thanks @brandon_owensby_2976 , we appreciate the additional context and it makes a lot of sense.
Just to give you more context on our end on why we aren't changing the software here very much, we aren't focusing very much on "download-try-buy" channel for BuildMaster (i.e. the way you're evaluating the product). Instead, it's sold as the technology to help implement Lean Platforms transformation, which necessities improving the development workflows.
One thing we'll be releasing as part of BuildMaster 2026 (coming fairly soon) are features to better handle parallel release tracks across multiple applications, including this new calendars feature:
-
Hi @dean-houston,
I think there might be a little bit of a misunderstanding. I'm not really evaluating the product. I'm selling the product. I've been using BuildMaster for over 10 years (I'm thinking 14 or 15) and most of which as a paying customer. I started a new job last year and I'm once again I've decided to try to sell your product to my employer. Previously I've just had to do a presentation on the product to get the company on board. Here, unfortunately, I need to do a little more show-n-tell rather than talk about the product. Not only that but this is the first place I've worked at that has a workflow quite like it does so it has brought up questions I didn't have to deal with, but I've never had any doubt I could/would accomplish what I needed. Since I know how hard of a sell this will be I'm trying to put extra effort in to coming up with the best demo possible and is leading to some of the questions.Thankfully I think I'm near the end of building what I need to build so hopefully will not be doing too many more posts on the forum. I really do appreciate all the time you and others have given to respond to my posts but I do feel a bit bad for how many and how complex my posts of been. Unfortunately I do not really know when I'll finally do the demo/presentation to my superiors, and I am kind of hoping I can wait until 2026 comes out before I do. I hate to sell a product and the version my pitch is based on is no longer the newest :-).
Thank you,
Brandon
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