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.
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