Interacting with releases from otterscript, especially from within a scheduled job

[brandon_owensby_2976]

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

[stevedennis]

Hi @brandon_owensby_2976 ,

You are correct, the $BranchName function is a build-information function that provides which branch a build was created from. It's a slightly different concept than the "default branch" that is associated with a release.

If changing your workflow to align with more standard practices isn't in the cards, then you may want to create a custom extension that will allow you to create your own variable functions and operations. This will make adding things like this easy and if it's something we think is generally useful, then we can generally add it in.

Although it's not supported in the SDK, if you take a reference to the core assembly (buildmaster.dll), you can invoke database commands like Releases_GetRelease to find that information easily.

Thanks,
steve

[brandon_owensby_2976]

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