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

I'm experimenting with the Git Repository Monitor and trying to replicate what we have with our current system. I have it creating builds but have a few questions on the settings as it isn't working as expected.

In my settings I set New Release Number to "pr-*" for starters but the release that was created was simply just "1". The "pr-" was totally ignored. On top of that I was curious if there was any variables that could be used in that field. I was specifically looking for a way to have the release number include the PR number. I looked through the documentation but was struggling to find specific stuff for that field.

The reason I'm using Docker.Desktop is not to run Linux on Windows but to run Docker. The goal was to mimic our dev and prod deployment which involves using helm files to update what version of a given image is deployed in a given environment. This part I have working. I just figured I'd try taking advantage of having docker installed to try out this feature of BuildMaster. I didn't expect it to be this troublesome though.

When I was working on it this morning I tried updating the tag to pull a specific version of the image to ensure it was Linux but that didn't work either. In fact it didn't change anything. I'll look at it again on Monday. Maybe someone will have some insight before then and help me out. Let me know if there is anything I add to the post to help. If I see a response over the weekend I'll definitely update the post with any requested information.

oh, and I will look up this docker run command. Unfortunately that doesn't allow me to use the built in test function in BuildMaster which could take away from part of my sales pitch. We'll see what I can do, and maybe you or someone else will think of something else.

Hi @stevedennis,
In a way I get what you are saying but either it isn't clear what I'm asking for or there is something else I'm still missing. Inedo has a registered image you can use to run BuildMaster as a whole in Docker. I take it that somehow this is different than running just the InedoAgent which is why there isn't a docker for just the InedoAgent. However, running BuildMaster on Docker means you are indeed running an agent on docker as well, it just happens to be running as part of the buildmaster web app which makes it all the more confusing. Of course maybe the version of BuildMaster that is running on the Docker doesn't include the built in agent?

The other part that doesn't make sense is you say you shouldn't be "running commands" but I'm not really wanting to do anything that different from your suggested solution which is image-based services. I realize that in my case the image would be running all the time instead of spinning it up for the one command. The primary reason I am going down this path at the moment is you don't support running the unit tests with the "image-based services". If you did, and I could get it to work (still haven't) then I likely wouldn't have a reason to go down this path.

Thank you,
Brandon

Hi @stevedennis,
As I mentioned in the original post I had already tried the image-based services although I did refer to it as containerized builds. That helps with the build part but not with the unit test part. Of course I can't get that to work at all. You actually responded to the post I have on that as well so you know I'm still working at that.

Unfortunately VMs are not an option for me at the moment. I'm trying to do this all on my laptop and so far I've been quite successful. I understand, based on your comment, I might be doing something a bit odd (I even suggested that in my original post) but wasn't expecting your reason. I do find your reason intriguing though. This job (been here almost a year) is the first time I've used Docker. They are using Docker (via Kubernetes) here to spin up web servers for web apps and APIs. Not all our apps have been migrated to this yet but they are essentially moving towards deploying all of our web apps and APIs to docker images instead of VMs. Maybe this isn't the best example but is what gave me the idea to try this, especially since I have docker running locally. In fact, the other confusing thing about what you said is that I know Inedo supports running BuildMaster in a Docker image so why not just the agent?

For the record, I'm not new to BuildMaster. I've actually been using BuildMaster for about 12 years now. I know you would typically put agents on the various servers you want to do things on and so why have one just running an agent. This is just to create a server for building. A very similar approach to the image-based services, it would support more commands than that feature does.

Bottom line is that this is my only option at the moment for this demo to have that capability fully (running both the build and unit tests in Linux). The bright side is that if I can get my other post figured out I that will be a huge plus in this direction. If anyone has any other thoughts on this I'd appreciate but I certainly understand if it isn't really feasible.

Thank you,
Brandon