Buildmaster fresh install / Unable to clone repository

carsten_1879

Hello. As you suggested i tried it with github. No issues there. But as you said it could be a problem with SSL i reconfigured the azure devops server to allow also http and disabled the redirect to https. Just to check if the issue then still exists. And the result: Even if you use pure http for the azure devops server you get the ssl error, which is very strange. Also tested this with another azure devops server at another site. Same problem there. Just to mention: The url i am using in buildmaster directly goes to the azure devops server, so there is no reverse proxy or something like this in between. Maybe you can reproduce the issue if i give you the azure devops url of my site. It's reachable for public. I created a test user and repository for you and created a personal access token, so you are able to reproduce the error at your site. Just give me a note where i can send you the credential informations so you can test it

stevedennis

Hi @carsten_1879 ,

Huh weird... so GitHub works, but your ADO Server doesn't. I bet it's related to some kind of TLS or something?? We may be able to see it with Wireshark or something.

Anyway if you can give provide us with credentials that would be great. We can then test on our new GitLibrary and see if it works.... maybe the solution is just to get you that instead.

Just email the info to support at inedo dot com, and include [QA-2678] in the subject line. But let us know when you send it, because we don't monitor that box.

Thanks,
Steve

carsten_1879

@stevedennis said in Buildmaster fresh install / Unable to clone repository:

[QA-2678]

Yes, perfect. I have sended the email with the subject [QA-2678] Additional informations
a few seconds ago... Hope to hear from you

stevedennis

@carsten_1879 excellent, thanks! Please give us a little time to review this.

We will also test it with the new Git library, which is available in buildmaster:24.0.8-ci.9 container image -- you have to go to Admin > Advanced Settings and enable it.

If you get a chance to try it yourself, please let us know. We are currently testing it ourselves on our main server.

carsten_1879

For sure. I tested it directly. Unfortunately this produces a 400 BadRequest error. So for first it seems to have no ssl problems. Too bad. One additional thing to mention which confused me a little bit: You allow to configure to access the azure devops via a PAT. If you use a PAT, then a username is obsolete, as the azure devops documentation says you should use a Basic Authorization to access the server which should be a base 64 encoded string create from "USERNAME:PAT" where USERNAME should be left empty. But in your UI the Username is a required field, which then for me doesn't make sense. Also to mention: If you ignore this and pass the username along with the pat, a git clone for example with this basic authorization also fails. Maybe it could be the case you did that wrong. But this would be strange, as you told me you don't have these issues. Or maybe you're testing against the cloud AzureDevopsServices. We are talking here about a on premise Azure Devops Server installation. Maybe their authorization mechs differs... Just some thoughts...

stevedennis

@carsten_1879 thanks for the update

We were able to reproduce this using your credentials, and It's definitely an "error reporting an error" on Linux. On Windows it's clearer ("too many redirects or authentication replays").

We do not test on ADO Server, but we quite a few customers users with it - who knows why it works for them but not you. Anyway, please bear with us as we figure it out.

stevedennis

Hi @carsten_1879 , just to give another update.

The issue appears to be localized to your ADO Server, perhaps it's the version or locale. The authentication header doesn't seem to make any difference.

Whatever the case is, the library we use, libgit2, simply cannot clone from it -- for whatever reason your ADOS is returning a 400 with some German error message when doing what should be a totally fine request. We did not test with git.exe.

Our new, proprietary library also does not work, but for a different reason - it looks like ADOS is using an ancient format (like from 2010??) for one of the reposes, so we don't support that yet. At least we think.

We'll need too spend a bit more time researching this, so it'll get pushed into the following weeks.

Thanks,
Steve

atripp

Hi @carsten_1879 ,

We should have a build of BuildMaster 2025 later this week that you can try out that includes the new library. We'll let you know!

Thanks,
Alana

atripp

Hi @carsten_1879 ,

Can you try out buildmaster:25.0.0-ci.23 container image?

I would do a new/fresh installation - new applications created in it should use the new Git library. It seems to work, but would like to see if it works for you as well.

Thanks,
Alana

carsten_1879

@atripp I was full of hope. Bute error messages are getting stranger than before.
Now we have: Unable to clone repository: HashDelta is not supported unless a repository is available.
:-(

carsten_1879

@atripp One additionally thing to mention. I tested this also with the test repository i given to you. This repository i was able to clone, but not others.

What i have found out: There is a bug in your implementation, which leads to the error given in my last reply:

If the repository name contains a dot (.) for example a repository with name: image.kubernetes-test

You'll get this error. So i think url or content encoding is not done the right way. I tried to rename one repository from: image.kubernetes-test to image-kubernetes-test and voila... That worked. So, maybe you can fix this too, so your implementation is usable for all valid repository names

gdivis

Hi @carsten_1879,

Thanks for trying it out. It is new, and has not been tested as much against older repositories. That said, we've reproduced this error and it's now fixed in the latest build - buildmaster:25.0.0-ci.28 if you would like to try it again. It's caused by older repos that don't support offset deltas being transmitted during a clone or fetch. Small repos that we used for testing ADOS so far were not large enough to have deltas at all, so those worked. So far as I can tell, the repository name containing a dot doesn't have any effect.

Thanks!
-Greg