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