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

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

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,

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

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

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

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

@atripp,
I'll be honest I'm not sure how we here completely. What I mean is that it appears that some how I've led you to the conclusion that we are using PRs but not feature branches which made it hard to get the help I needed. I appreciate the information you provided as that finally helped us figure out the disconnect.

We are indeed using feature branches. The primary difference in what we are doing and what you are doing is the timing in which an automated build is generated which leads to a few other smaller differences.

When working on a ticket we create a feature branch for that ticket. At this point everything we do is local to our personal computer and we commit to save our work. Once we feel we are code complete we generate the PR and mark it ready for code review. The PR generates a build and one of the requirements on git repo is that a PR must have a successful build before it can be merged. Once the build finishes and the reviewers have approved the code it can be merged in to master which generates the official build which is first deployed to our dev/test (basically the QA environment but the call it dev) environment and then if everything is good it eventually goes to production.

Unfortunately my lack of understanding in this area of your application can me from asking direct clear questions. I had 2 core issues I was trying to figure out.

• Best way to set up the creation of these builds of a PR
• How to clean up the builds when no longer needed

Even though they are 2 distinct issues the second one is affected by the first one as I'm come to find out. Originally I thought the best thing to do was to have it create a release based on PR # so you could see the history of the builds that occurred for that PR. For example if a unit test failed so you had to do a subsequent build to fix it. The other part was to make it easy for developers to find the build they generated in case it failed so they could see why as there could be multiple developers with feature branches on the same application. This method created the issue of a release that then needed to be purged once the PR and branch were gone. I saw no built in feature for this. You have a scheduled job feature but I didn't want to have to set that up individually for every app so I tried to create a generic one but your otter commands are set up more for running in the context of app/release/build then globally and that is where this post came from.

After some experimenting I realized I could set the monitor to just create a build with a specific pipeline and that seemed to be the ticket. It doesn't clutter up the app with extra releases you have to purge and the you can still see the history of your tickets build by going to the branch and viewing builds for the branch.

I'm still not entirely sure how the clean up will work there but I'm going to cover that in a different post as I plan on having a post specifically about just the retention policy feature.

I hope that clarifies things a bit. I'm not sure if my colleagues will mind looking for things by branch of PR # but in some ways I personally think it might be nicer.

Thank you,
Brandon

Hi @stevedennis,
Can you provide more detail in your response? You mention, for example, standard practices. You don't however mention for what, what those are, or what features BuildMaster has to support them. Maybe you mean in terms of doing things on a build bases. If that is what you meant it might be helpful if you knew what I was doing which I unfortunately didn't provide in my original message.

The goal of my script is a clean up script for PRs since you guys do not have that feature built in. The purpose behind this is I want a PR to kick off a release/build to prove that it will actually build and set a marker on the PR to allow it to be merged. Once the PR is merged those releases/builds are no longer useful. Unfortunately, none of your retention rules take that in to consideration (part of why I asked in the previous message if you had any enhancements coming in the next major build that might be helpful for me). On your note about standard practices, I'm assuming this might be where it is targeted (the PR workflow). One of our colleagues mentioned in another post trying things differently and even doing releaseless builds but they did support the idea of having some build verification on a PR before allowing it to be merged. I'm not entirely sure, however, how a releaseless build might help. I did think about it but my fear is making the UI more cumbersome in finding what you are looking for. What I mean by that is everything is listed together (although I haven't yet tried a mix of releases and releaseless builds but I will) so naturally the PRs would continue pushing the main release down. Also if PR releases aren't being removed as soon as the PR is merged then the main release stays pushed down and there are more PRs to go through to find yours.

In my original message I left it a little more open to hopefully provide more flexibility in your response. This time going to try a list of specific questions.

• Do you have any upcoming features that might help with any of this?
• The call to Releases_GetRelease requires a release id but fetching the releases just gives me release numbers. How do I bridge that gap?
• What is the standard practices you referred to for the workflow?

I'm not sure I'll be able to before you respond but I do plan on investigating writing an extension for a different purpose anyways so I'll also look at one for this PR management too. In addition to the bullet points feel free to add anything you might find useful.

Thank you,
Brandon

Hi @gdivis,

This actually clears up a lot for me. I haven't made the adjustment yet but will do so very soon. Thank you so much for bringing it all together.

Thank you,
Brandon

Buildmaster has some nice features when it comes to git and even monitoring git. Unfortunately it falls a hair short for what I need and I'm trying to bridge the gap with an otter script. This is having me fetch request info to make other calls. I'll give more details but the overall goal is to see if I'm not going about this in the way you'd recommend as well to see if there is any changes planned in the next major release that might help with this.

First some specifics on where my troubles are. When writing a script I prefer OtterScript because of all the built-in commands and the help you can get from the GUI as you go. I also figured that when interacting specifically with BuildMaster it would provide the most easy to use functionality. Unfortunately that didn't prove to be true in all cases, especially when running outside the context of a specific app, like in a scheduled job. I did find, however, that you can call the Buildmaster rest API to get extra functionality in some cases. Where I can't seem to bridge the gap is I'm getting a list of applications in the otterscript and I can get a set of release numbers but the API I want (which is Releases_GetRelease) in this case requires application id which I don't have, I just have name.

What I'm after here is to get the branch the release is linked to. Otterscript seems to have a way to do it for a build not a release. I tried treating the build as an optional parameter but it just threw an error for an invalid application name. I thought the error was odd but didn't know how to get around it so I pivoted. If there is a way I can use that function that would be great.

The ultimate thing I'm after (which I'm incredibly close on) is go through the active applications that have a git monitor on them and check the releases on that app to see if there are any created off a pr branch where the pr is no longer open so I can purge those releases. If there is something in an upcoming major release that might help with I'd appreciate learning about that too.

Thank you,
Brandon

Hi @gdivis

I appreciate that extra info and that is a really nice bit to know. I haven't had a chance to play this yet and if I can I may add another comment on this post with some updated information. The part that I'm not quite understanding from your post and the corresponding documentation is how it connects to the issue I had and fixed with the code in my original post. My issue was never (that I knew of) with what showed up in the Buildmaster UI as I was using text view most of the time. Granted I did switch to the visual editor at one point to see if it provided help on the output part, but it didn't. It did however help me fix the input part (corrected the params declaration).

What I'd like to know is if adding that help is going to somehow wire something up behind the scenes to prevent me from having to do that crazy Write-Output line in the ps1. I can see how it would help me with the syntax of the Otterscript but that isn't where I was having my issue. For clarity my issue was that if I set the variable like you did the $resulttext in your example, it wasn't being set in otterscript. I couldn't get it to work until the changed the ps1 to add one more line to do the Write-Output I posted above. Hopefully that will help you understand my issue more and help with improvements for the 2026 version.

Thank you,
Brandon

After many hours (over multiple days) I was finally able to get data back from a powershell script with with PSCall (which is really PSCall2 under the hood). Unfortunately the documentation on your site doesn't have any information about what is needed in the powershell side of things. I ended up using cursor to analyze the scripting extension dll and help me figure out what you code was expecting. I was surprised at how specific the answer was, especially since it appears to missing in the documentation and in my eyes is not anything anyone could guess on their own.

I had to create an object in ps and turn it into JSON (which I had already done anyways) but having the variable was not enough. I had to do a Write-Output with other specific parsing text. Here is the resulting code:

Write-Output "!INEDO_VAR!RepositoryInfo!$RepositoryInfoJson"

I'm hoping that posting this here will help someone in the future and maybe even get the documentation updated. Or maybe you'll tell me a better way to accomplish this same thing.

Thank you,
Brandon

I have code that is trying to get Token using $CredentialProperty and it says it fails with "not configured to allow access to encrypted values" but this doesn't appear to be the case. First here is the line of code in question:

This is executed where $BuildMasterApiKeyName = "global::BuildMaster"

$CredentialProperty($BuildMasterApiKeyName, Token);

The execution log shows the error: The specified credential property "Token" is marked as encrypted and the "global::BuildMaster" credential is not configured to allow access to encrypted values.

Here is a screenshot showing that property as checked:

Thank you,
Brandon

Hi @atripp,
I finally have time to work on this again and wanted to respond to your last message regarding releaseless builds. Honestly, I'm not entirely sure how that helps me but more importantly look at that link you gave me doesn't even tell me how to set that up. Can you point me to some documentation regarding that feature? Maybe if I play with it I can determine if I want to use it as part of my pitch or not.

Thank you,
Brandon

Hi Alana,
Just wanted to let you know that restarting the service did fix the issue. Thank you for the suggestion.

Brandon

Alana,

I totally understand everything you are saying and in the nearly 15 years I've being using BuildMaster this is the first time I've ever even considered anything like this. To be honest I don't like how our builds/releases are currently handled but being as new as I am with the company I don't have a lot of power there. I'm on this project to hopefully gain a little influence in this area though.

One thing I've learned in my time with this company, is there is at least some benefit to triggering a build for the PRs so you can require a successful build prior to allowing the PR to merge. I love the way Buildmaster handles things with releases, I just was hoping you had something to help separate the different types of release as you obviously support create a release off of a PR. Maybe that feature is something you added but not something Inedo fully believes in so you haven't spent a lot of time on the features around it (which would be totally understandable).

To be clear I'm not looking to 100% replicate the UI we currently use (I don't like most of it anyways). The only thing I'm interested in is keeping someone from losing the primary release in a bunch of PR releases. I had hoped that being able to add PR in front of the release name would help but it appears you guys support the number and not the name in that feature. If you have another idea up your sleeve I'd appreciate it, if not I understand.

Thank you,
Brandon

Thank you,
Brandon

I created a scheduled task that points to an OtterScript. I created the script it is pointing to as a global script via the Administration screen. Even though I can clearly see the script and the name I keep getting the error

System.FormatException: "Purge_Orphaned_Feature_Releases" is not a valid DeploymentScript identifier for the "global" scope.

when it attempts to fire the scheduled task.

The original name was Purge Orphaned Feature Releases but I changed it to use underscores thinking the spaces had something to do with it. I even tried prefixing it with global::. I'm hoping someone can tell me what is going on so I can get this working.

Here is a screenshot showing the script is defined globally

Here is a screenshot showing the current configuration for the scheduled task

Thank you,
Brandon

I have install of BuildMaster with a couple of test applications connected to Bitbucket and ProGet. I'm testing out the native api to see how I can write a script for maintenance purposes and when I tried getting secure resources using Postman to I get a 500 Internal Server Error with the following message: Serialization and deserialization of 'System.Type' instances is not supported. Path: $.Resource.CompatibleCredentials.

I'm currently using 2025.11. I'm hoping someone can give me a workaround or let me know another version is coming out soon that fixes this issue. I see that 2025.12 is out but the release notes do not specify it fixed anything about this specifically.