Topics created by brandon_owensby_2976

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 , Thanks for the feedback, we appreciate it :) There's definitely a value in building before merging; if you haven't already, I'd check out that feature branch article, as it outlines the pattern we use for it. In general, the way I would try to configure is: consider using a releaseless-build if you don't yet know the release it's targeting use a different piepline so it's visually clear; the stages may be Build -> Test -> Merge clean up the builds aftewards That said, this isn't the most popular workflow in BuildMaster, so it may not be the most intuitive to implement or feel a bit clunky. We don't have a lot of public examples, but the inedo-docs application is the closest to a Gitflow, releaseless type of workflow. Commits to master branch auto-deploy to live site, where as branches can only go to test: https://buildmaster.inedo.com/applications/136/overview No idea if that's helpful, but just FYI Cheers, Alana

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