Hey there,
yeah, there are different ways to achieve this.
# PAT This seems to be the most difficult one: Git has to send an additional HTTP Authorization Header to fetch stuff: https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-pe...
So you would need to modify LAVA to do this.
Maybe it will work out if you use https://user:password@repo.example.com/ syntax for repo URL, with user being empty and password being your PAT (that's why there's a colon in the example above) Be careful, the PAT might show up in different places, I would not recommend using this way! I didn't test this.
# SSH Azure DevOps supports git via SSH - that's the easier way to go (even for daily development), put your public key on the server, and clone repo using this key.
This would work if you properly set up your .ssh/config on the LAVA server so you can clone the ADO repo. Drawback: With current LAVA you would have to do this for the root user of your server, as LAVA uses this to clone. I have a not yet finished MR open to use the lavaserver user instead: https://gitlab.com/lava/lava/-/merge_requests/2259 It is "not yet finished" because it doesn't pass the tests (as they are run on docker), but it is usable for a Debian install of LAVA. I will have to find time to polish this and get it merged.
Be careful: With PAT and SSH, on ADO it is not possible to restrict access to single repositories. So these credentials will have at least read access to all the repositories your ADO user has access to - with SSH even write access. Take caution!
# Gitolite (or other git server) So the safe way to go (security wise and fail-safety wise) is to set up a separate git server locally on your LAVA server. I use Debian package gitolite3 for this, having set up a separate LAVA user (cloning repos with SSH). I'm just pushing repositories that LAVA needs access to (and restrict LAVA user accordingly).
Development workflow is to push your local repo to this repository - and push to ADO repository for backup reasons.
Choose what fits your workflow and security considerations.
Best regards
Stefan
On 1/25/2024 9:48 AM, Milosz Wasilewski wrote:
Hi Michael,
I think the simple answer is that LAVA only supports git repositories without passwords. I think it might be possible to store the credentials in git global config on the dispatcher, but I haven't tried this. Under the hood the usual git client is used. If there is a way to configure credential manager for git not to ask any interactive questions, this might work.
Best Regards, Milosz
On Wed, Jan 24, 2024 at 10:34 PM michael.peddie@gallagher.com wrote:
Hi,
As stated in the subject, I was wondering if it is at all possible to use a repo on Azure DevOps instead of a GitHub one. I have been using a GitHub repo thus far, and it works just fine, but I need to move my files over to DevOps.
According to the docs here: https://docs.lavasoftware.org/lava/actions-test.html only git is supported at the moment, with URL and tar planned for. Would URL work for this if support came in at any point? Or would azure need its own support?
Or should git work and there is something wrong with the repo URL I am using? Because the particular error I get is that the password could not be read (I'm using a PAT in the link, like I did for GitHub)
Best Regards. Michael