@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