How can I get kas to use my $HOME/.gitconfig?

[salerio-gs]

I am behind a proxy which blocks git:// so I use a .gitconfig to replace git:// with https://, I tried to use kas but fell foul of this issue.

[henning-schild]

.gitconfig is the wrong way. Same as PREMIRRORS. It is really just a last resort and not reliable.

What you most likely want is GIT_PROXY_COMMAND="oe-git-proxy" and https://github.com/siemens/kas/blob/master/kas-container

[salerio-gs]

Thx I’ll give that a try...

[dkruces]

Hi @henning-schild and @salerio-gs,

I'm trying to setup the same here and use GIT_PROXY_COMMAND but I can't achieve the replacement I get with git config insteadof.

Here what I do with git config:

git config --global url."https://gitlab-ci-token:<token>@gitlab.com/".insteadOf git@gitlab.com:

What would be the equivalent using GIT_PROXY_COMMAND and the kas-container and/or just kas?

What I tried: With kas container I do:

docker run --rm -it -v $PWD:$PWD -w $PWD ghcr.io/siemens/kas/kas

builder@7aeebcdad58d:/home/daniel/wd/software/distro/yocto/builder$ env | grep -i proxy | sort
GIT_PROXY_COMMAND=oe-git-proxy
NO_PROXY=*

Then, I configure the proxy env vars following this: https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy.

http_proxy=$http_proxy https_proxy=$https_proxy GIT_PROXY_COMMAND=$GIT_PROXY_COMMAND NO_PROXY=$NO_PROXY kas checkout .config.yml

But I get permission errors:

--- Error summary ---
fatal: could not create work tree dir '/home/daniel/wd/software/distro/yocto/builder/repos/meta-qtec-bsp': Permission denied

2022-08-22 13:45:27 - ERROR    - Command "/home/daniel/wd/software/distro/yocto/builder$ git clone -q git@gitlab.com:qtec/software/distro/yocto/meta-qtec-core.git /home/daniel/wd/software/distro/yocto/builder/repos/meta-qtec-core" failed

Any help?

[g4bwy]

Hi,

Just adding more information about this issue, since the proposed solution using oe-git-proxy disregards some use cases and leaves some of us stuck outside due to kas denying use of ~/.gitconfig (in my case, a self-hosted corporate gitlab server doesn't allow external ssh access, but many recipes are using protocol=ssh in SRC_URI, with a team policy of not switching to protocol=http by default instead).

GIT_PROXY_COMMAND doesn't work for ssh urls (eg. "git@gitlab.com:" which is implicitly parsed as ssh by git)

Also, as stated before PREMIRRORS isn't suitable either: it will work for the first fetch, but on subsequent updates of an already cloned repository, bitbake will bypass PREMIRRORS unless BB_FETCH_PREMIRRORONLY is set, which incidentally forces BB_NO_NETWORK (not sure exactly why this is so, but there's no way to bypass that without forking poky/bitbake so it's a no-go for us)

However I found a workaround for this by overriding FETCHCMD_git in local_conf_header:

local_conf_header:
  99_external_git: |
    FETCHCMD_git = "git -c gc.autoDetach=false -c core.pager=cat"
    FETCHCMD_git:append = " -c url.'https://gitlab.example.com'.insteadOf='ssh://git@gitlab.example.com'"

combined with GIT_CREDENTIAL_HELPER="store --file ${HOME}/.git-credentials" in the environment before launching kas (to avoid hardcoding gitlab tokens in the config), this effectively achieves the same result as using a .gitconfig to rewrite any type of git URL.

cheers,

[henning-schild]

@g4bwy i guess the real problem is that PREMIRROR tricks only allow to change the URI but not the protocol

In fact something i also once faced and found another hack, but related to a gitlab bug and not a "mirror on the wrong proto"

You should also go back and question how you can mirror "git+ssh" on "git+https", if the layers you mirror dictate ssh the "team policy" is the problem. Might as well mirror to clearcase and act surprised when git shas can not be found.

[g4bwy]

changing the protocol using PREMIRRORS actually works, albeit it's scarcely documented, here's how it can be done:

PREMIRRORS:prepend = "git://gitlab.example.com/.* git://gitlab.example.com/PATH;protocol=https \n "

when doing this, bitbake seems clever enough to replace any existing protocol with https. I used this trick until discovering I couldn't fetch again over an already cloned repo (and doing a cleanall everytime is just not practical when you need to clone large repos like linux kernel with full history)

unfortunately, as in many organizations, trying to solve this issue by challenging the team policy is a no-go...