Bitbake not picking up on GitLab CI ssh to https rewrites

[Slawek Wojtysiak]

I'm new to kas. My goal is to have a kas project that developers can build using their SSH credentials, but also allow Gitlab to build utilizing the CI_JOB_TOKEN. Doesn't seem like anything out of the ordinary for this project.

I've gotten kas to rewrite the layers with KAS_PREMIRRORS, but I cannot get bitbake to properly pick up on the ssh->https+token rewrite.

I've read the documentation about credential handling, read handful of bugs here on GitHub issues and the Google Groups, but I cannot pinpoint the problem.

It seems like git may be picking up on the rewrite, but it seems to truncate the username and token, maybe? 

I have added the permissions for the job token for all projects that will be accessed by the job. I have also manually tested using the CI_JOB_TOKEN and it works.

Excerpt from my pipeline log

remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password. See https://mygitlabserver.com/help/topics/git/troubleshooting_git#error-on-git-fetch-http-basic-access-denied

fatal: Authentication failed for 'https://mygitlabserver.com/product/rootfs/sources/firmware.git/'
The variable dependency chain for the failure is: SRCPV -> AUTOREV[vardepvalue]

My SRC_URI are like this

SRC_URI= "git://g...@mygitlabserver.com:2289/product/firmware.git;protocol=ssh;branch=master"

What I've tried:

1) .gitlab-ci.yml entry in the before_script section

git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@mygitlabserver.com/".insteadOf "ssh://g...@mygitlabserver.com:2289/"

2) .gitconfig file
[url "https://gitlab-ci-token:${CI_JOB_TOKEN}@mygitlabserver.com/"]
insteadOf = ssh://g...@mygitlabserver.com:2289/
... as well as the export of the file in the pipeline

export GITCONFIG_FILE="cicd/.gitconfig"


One thing that concerns me is that I NOT seeing mentions like this in the pipeline according to issue GitHub Issue #128
"Adding GitLab CI ssh -> https rewrites"
"Running on GitLab CI"

Could it be that I'm running my kas binaries out of python venv?

run_kas.sh
set -euo pipefail

export KAS_FILE="kas/myproduct-rootfs.yml"
export script_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd -P)"

export DL_DIR="/data/yocto/downloads";
export SSTATE_DIR="/data/yocto/sstate-cache"

# setup kas
git clone https://github.com/siemens/kas.git kas-source
pushd kas-source
python3 -m venv ./  
source bin/activate  
pip3 install . # installs required packages and modules  
source bin/activate  
popd

# go up one level and execute kas build
KAS_CONTAINER_ENGINE=podman kas-source/kas-container build "$script_dir/../${KAS_FILE}"

[Slawek Wojtysiak]

I guess I did not read the documentation well enough. I just noticed the "variable scope" on the Environment Variable page and the fact that CI_* variables only apply to using 'kas' directly. 

"When invoking the build via kas-container, make sure to also forward the corresponding environment variables into the container."

All the issues I read through and examples I found made me convinced that kas-container was supposed to act the same as kas. Took me three days to realize this...

I did fork kas (https://github.com/k3wals/kas) and started modifying it to dynamically pass on the CI_JOB_TOKEN and CI_SERVER_HOST variables. I did find the .netrc file under a /tmp/... directory but my auth is still failing during bitbake.

[Slawek Wojtysiak]

Got it working, but requires my modifications in kas-container to pass through the two CI variables.  With kas now creating the .netrc file after starting the container,  I no longer needed the gitlab-ci-token:${CI_JOB_TOKEN} portion in the .gitconfig file. I suppose I could keep updating the source to get the _setup_gitlab_ci_ssh_rewrite() function to get called as well. 

Has the kas-container simply not evolved to being dynamic with GitLab CI, or am I just using it wrong/funny?

----

diff --git a/kas-container b/kas-container
index aea7be8..0238dfa 100755
--- a/kas-container
+++ b/kas-container
@@ -584,6 +584,12 @@ if [ -n "${KAS_REPO_REF_DIR}" ]; then
                -e KAS_REPO_REF_DIR=/repo-ref
 fi

+if [ -n "${CI_JOB_TOKEN}" ] && [ -n "${CI_SERVER_HOST}" ]; then
+       set -- "$@" \
+               -e CI_JOB_TOKEN=${CI_JOB_TOKEN} \
+               -e CI_SERVER_HOST=${CI_SERVER_HOST}
+fi
+
 for var in TERM KAS_DISTRO KAS_MACHINE KAS_TARGET KAS_TASK KAS_CLONE_DEPTH \
            KAS_PREMIRRORS DISTRO_APT_PREMIRRORS BB_NUMBER_THREADS PARALLEL_MAKE \
            GIT_CREDENTIAL_USEHTTPPATH; do

[Florian Bezdeka]

On Mon, 2025-01-13 at 15:07 -0800, Slawek Wojtysiak wrote:
> Got it working, but requires my modifications in kas-container to pass through the two CI variables.  With kas now creating the .netrc file after starting the container,  I no longer needed the gitlab-ci-token:${CI_JOB_TOKEN} portion in the .gitconfig file. I suppose I could keep updating the source to get the _setup_gitlab_ci_ssh_rewrite() function to get called as well. 
>
> Has the kas-container simply not evolved to being dynamic with GitLab CI, or am I just using it wrong/funny?
>
> ----
>
> diff --git a/kas-container b/kas-container
> index aea7be8..0238dfa 100755
> --- a/kas-container
> +++ b/kas-container
> @@ -584,6 +584,12 @@ if [ -n "${KAS_REPO_REF_DIR}" ]; then
>                 -e KAS_REPO_REF_DIR=/repo-ref
>  fi
>
> +if [ -n "${CI_JOB_TOKEN}" ] && [ -n "${CI_SERVER_HOST}" ]; then
> +       set -- "$@" \
> +               -e CI_JOB_TOKEN=${CI_JOB_TOKEN} \
> +               -e CI_SERVER_HOST=${CI_SERVER_HOST}
> +fi
> +
>  for var in TERM KAS_DISTRO KAS_MACHINE KAS_TARGET KAS_TASK KAS_CLONE_DEPTH \
>             KAS_PREMIRRORS DISTRO_APT_PREMIRRORS BB_NUMBER_THREADS PARALLEL_MAKE \
>             GIT_CREDENTIAL_USEHTTPPATH; do
>
>

kas-container is designed as a helper for developers to locally start
the kas container based on the kas container image available in the
github container registry. If you want to run kas as gitlab-ci pipeline
(job) you normally don't need that script.

Something like

default:
image: ghcr.io/siemens/kas/kas-isar:4.6

in your .gitlab-ci.yml should do.

kas will auto-detect the gitlab-ci environment then - activating the
ssh to https rewrite mechanism.

HTH,
Florian

[Jan Kiszka]

That said, if it is only about forwarding a few variables we could add
them to kas-container nevertheless.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Slawek Wojtysiak]

Thanks for the inputs. I failed to notice that GitLab does have support for Podman instead of docker. The runner executer is still called "docker" so I never looked into it further.

I think I'm still going to continue using kas with my modifications until I figure out the pipeline syntax for use directly with a container image defined as Florian suggested.

Jan, perhaps adding an option to kas-container to specify a .env file and using the --env-file option for the container is a nice universal option.

For example

kas-container --env ~/.env build mysystem.yml

PS. 

I noticed is the kas-container documentation does not mention the ability to add extra bitbake args at the end like kas can. I only noticed this while browsing through the source.

kas-container --env ~/.env build mysystem.yml -- --continue

I can make a PR for both of these changes if you'd like, but I'm new to this project. Let me know.

[Jan Kiszka]

On 14.01.25 19:45, Slawek Wojtysiak wrote:
> Thanks for the inputs. I failed to notice that GitLab does have support
> for Podman instead of docker. The runner executer is still called
> "docker" so I never looked into it further.
>
> I think I'm still going to continue using kas with my modifications
> until I figure out the pipeline syntax for use directly with a container
> image defined as Florian suggested.
>
> Jan, perhaps adding an option to kas-container to specify a .env file
> and using the --env-file option for the container is a nice universal
> option.
>
> For example

> kas-container *--env ~/.env* build mysystem.yml
>

The vision for the CI setup would rather be some out-of-the-box user
experience.

> PS. 
> I noticed is the kas-container documentation <https://
> kas.readthedocs.io/en/latest/userguide/kas-container.html> does not

> mention the ability to add extra bitbake args at the end like kas can. I
> only noticed this while browsing through the source.
> kas-container --env ~/.env build mysystem.yml -- --continue
>

It's documented via the kas plugins (e.g.
https://kas.readthedocs.io/en/latest/userguide/plugins.html) -
kas-container is just the a wrapper around those. Maybe you can propose
to add some reference to those, to make that clearer?

> I can make a PR for both of these changes if you'd like, but I'm new to
> this project. Let me know.

We would rather take patch here. It would also involve passing through a
few more env vars than the two you had, just to make things consistent.

Thanks,
Jan

> --
> You received this message because you are subscribed to the Google
> Groups "kas-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to kas-devel+...@googlegroups.com <mailto:kas-
> devel+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/kas-
> devel/bc17ae9d-29e2-4b80-88c9-805ab368d1cfn%40googlegroups.com <https://
> groups.google.com/d/msgid/kas-devel/
> bc17ae9d-29e2-4b80-88c9-805ab368d1cfn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[Slawek Wojtysiak]

Czesc Jan,

I'm sorry I missed that in the documentation. It looks like I also have overlooked the kas-container "--runtime-args" option which is allowing me to pass in the random environment variables and some extra volume mounts now.

One thing I found necessary to do on my host was set --pids-limit=1 because otherwise I was getting "resource not available" errors non-stop. I was starting to think the ghcr.io container image was sub-par but it was just my settings.

I no longer have any suggestions. Thanks for your help.

Slawek