0

The problem is that the command:

git rev-parse HEAD

inside of the retrieved repository fails when retrieved under https but only on our Jenkins server called by bitbake.

I have switched our Jenkins server build back and forth between: https://git.multitech.net/cgit/mlinux.git/ and git://git.multitech.net/mlinux.git

If I do this outside of bitbake and Jenkins this works fine. Running in Jenkins works fine. Running bitbake outside of Jenkins is fine. But the combination of bitbake and Jenkins fails.

I ran strace, and in a successful git rev-parse HEAD, it calls geteuid().

In the unsuccessful case, run from bitbake, it never calls geteuid(). It is supposedly running as the same user. In the same bitbake execution, it returns the same UID every time in other commands run prior to git rev-parse HEAD.

If you look at the execution of git, it calls lstat on the directory in question eight times and gets st_uid=1001 each time. Each time the result is 0, which the source also checks.

The error:

fatal: detected dubious ownership in repository at '/home/jenkins/workspace/mlinux/nightly'
To add an exception for this directory ...

Since the code never called geteuid() in this case, how does it know the directory is of dubious ownership? I have also tried using env -i to remove the environment from the execution of git by wrapping it with a shell script. This did not help.

root@buildslavemtcdt3dm2:/home/jenkins/workspace/mlinux# find nightly ! -user 1001
[Nothing is returned]
John Klug
  • 121
  • 3
  • 1
    Hm, I have just had a sudden memory of "fakeroot" here: some of the Linux build software *pretends* (via libc wrappers) to be running as root. They supply a fake `geteuid`/`getuid` that just returns 0. If this is the case for bitbake, that would explain the problem, and if so, you can fake things out by setting the environment variable `SUDO_UID`. – torek Aug 20 '22 at 08:06
  • I did an echo of "SUDO_UID is \|$SUDO_UID\|" in our build. SUDO_UID is apparently not set. I doubt if we ever do sudo in our build, nor does Jenkins set it. I don't recall sudo being a pre-requisite for bitbake either. – John Klug Aug 22 '22 at 15:24
  • No, you misunderstand me: bitbake may be using the old `fakeroot` *library* so that when Git runs, *Git thinks it's running as root*. To defeat Git's complaint here, *you* can set `SUDO_UID` so that not only does Git think it's running as root (even though it's not), Git will think it's running as root because someone ran `sudo git`. That is, we're trying to use two wrongs to make a right here. – torek Aug 22 '22 at 15:57
  • This is what I did: ```$ grep jenkins /etc/passwd jenkins:x:1001:1001::/home/jenkins:/bin/bash $ ls -ld nightly drwxrwxr-x 11 jenkins jenkins 4096 Aug 23 18:51 nightly``` So we want UID 1001 and I add this to the build: ```export SUDO_UID=1001 export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE MTS_INTERNAL_GIT SUDO_UID"``` After the build git still complains about the dubious directory. No change, unfortunately. So this is all that has worked so far: `git config --global --add safe.directory /home/jenkins/workspace/mlinux/nightly` – John Klug Aug 24 '22 at 00:24
  • OK, either you don't have the version of Git that checks `$SUDO_UID` (this was a later addition than the `safe.directory` stuff) or something in the sequence cleaned out the env variable. It's probably better to just use the `git config --global` method anyway; the `SUDO_UID` trick isn't documented and could go away again in the future. – torek Aug 24 '22 at 02:10

0 Answers0