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

@brandon_owensby_2976 fantastic!! Thanks much; I'll let our technical writing team review/accept it, They should within a day or so -- Dean

Hi @brandon_owensby_2976 , Thanks for clarifying; it got a little distracting with the desire to have PR cleanups and specialized variables! We also see a lot of anti-patterns in Git repositories, such as using PRs for workflows, because that's how open source projects tend to work. Anyway, it sounds like you figured it the first part, which is to set the monitor to just create a build with a specific pipeline (e.g. "Feature Branch" pipeline). The next step, just use a retention policy that targets builds that have completed the pipeline. For example: https://docs.inedo.com/docs/buildmaster/builds-continuous-integration/buildmaster-ci-git-workflows/buildmaster-git-feature-branches#cleaning-up-feature-branch-builds-with-retention-rules

Glad I could help! We'll get that documentation updated as well.

Hi @brandon_owensby_2976, I wasn't able to reproduce this issue, but looking over the code, I can see a few scenarios in which "not configured to allow access to encrypted values" will trigger, even if that's not accurate. It's not trivial to rewrite that to provide a more accurate error message or credential resolution, so we'll add this to our BuildMAter 2027t roadmap and review it more closely then. In the meantime, I would just use a variable and duplicate the information. Thanks, Steve

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

Hi @brandon_owensby_2976 , Looks like this is a regression in BuildMaster 2025 from a library upgrade; we will address it via BM-4017 in an upcoming release, either this Friday or the following cycle. Thanks, Alana

Hi @brandon_owensby_2976 , You can configure release settings on an application-by-application basis under the Settings tab. In this case, you'd set Release Usage to be Optional or Disabled. If Release Usage is set to Required, users must select a release when creating a new build; this was the deefault in older versions of BuildMaster. https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases Cheers, Steve

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 @brandon_owensby_2976, Argo CD is free / open source and no license is required. You'd be better off learning that than trying to do Kubernetes another way. FYI there's also Kargo, which is a "wrapper" that sits on top of ArgoCD and has some kind of promotion workflow outside of typical GitOps (pull requests I guess?). To be honest, I really don't know if the Kubernetes extension even works; it was originally intended for Otter, to create a "Desired state" and offer an alternative to Git-based approaches. But there's just no demand and GitOps is just the Kubeernetes standard. We haven't tested it in years. We do not plan on migrating it to the next SDK version. It's just a light wrapper around kubectrl, which has probably changed over the years. If you really wanna mess with Kubernetes outside of Argo CD I would just run kubectrl apply/replace directly. Good luck!!

Hi @brandon_owensby_2976 , It sounds like you're on the right rack with troubleshooting; the issue is definitely on the server-side in this case, so I asked ChatGPT. Who knows if any of this is accurate, but... This is a very common situation with older versions of Bitbucket Server (especially pre-6.x / pre-7.x era, but even up to some 7.x versions in certain setups). The REST API (e.g. /rest/api/1.0/...) and the Git Smart HTTP protocol (/scm/.../info/refs, /git-upload-pack, etc.) are handled by different authentication filters in Bitbucket Server. Most likely you're using a Personal Access Token / HTTP Access Token (most frequent cause in older versions). In many Bitbucket Server versions (especially ≤ 7.17–7.21), HTTP access tokens were designed mainly for REST API and did not work reliably (or at all) for Git over HTTPS in many cases. As a workaround , you need to use a real username + password (or username + app password if 2FA is on) for Git operations We've seen similar in really old version of ADO, GitHub, etc, where API tokens wouldn't work for Git. Anyway, I would try that - at least from the curl side of things. And maybe upgrading will help as well. If it works, then you'll likely only be able to use a Generic Git repository with a real username/password -- and just create a special builds user which effectiveely acts like an APi key. Cheers, Steve