Question 80943 in Docker Question posted in
The official documentation can be found here.

Detected dubious ownership in repository GITLAB CI/CD – Docker

I am facing this issue during try to deploy script with gitlab ci/cd:

Initialized empty Git repository in C:/builds/Tri.BuiV/test-gitlab-cicd/.git/
fatal: detected dubious ownership in repository at 'C:/builds/Tri.BuiV/test-gitlab-cicd'
'C:/builds/Tri.BuiV/test-gitlab-cicd' is owned by:
    'S-1-5-83-1-1989435290-1148643240-1709935003-3943614564'
but the current user is:
    'S-1-5-93-2-1'
To add an exception for this directory, call:
    git config --global --add safe.directory C:/builds/Tri.BuiV/test-gitlab-cicd

I tried:

git config --global --add safe.directory C:/builds/Tri.BuiV/test-gitlab-cicd

But the same error, why?

enter image description here

I tried:

git config --global --add safe.directory C:/builds/Tri.BuiV/test-gitlab-cicd

But get the same issue.

Tags:

2

Answers


  1. 0

    If the error persists, it probably means your git config --global (which impacts %USERPROFILE%.gitconfig) does not use the same account as the one running your GitLab CI/CD.

    If GitLab runs with a different account, it might try to access a folder initially created by you.
    The GitLab pipeline itself would need to include:

    git config --global --add safe.directory $CI_PROJECT_DIR

    This I what is being automatically added for GitLab 15.8 in MR 3538.

    The solstice333 points out in the comments to gitlab-org/gitlab-runner issue 29022, where Kevin Navero explains:

    I found a workaround for my case.

    To clarify my environment a bit more, I’m using docker-windows executors/runners with powershell on windows-server.
    Forget what I mentioned earlier about suspecting git config being run under a different container than git clone/fetch. I do not believe that is accurate anymore.

    Gitlab-runner 14.10.1 works for me, so I rolled back to that.

    As a result, somehow the "dubious owner" error is pushed to a later point in runtime, within the main .gitlab-ci.yml build script.
    This allows me to do git config --global --add safe.directory ... in the pre_build_script, as opposed to any of the other pre_* scripts. I have no idea where or what containers the other pre_* scripts run in.

    AFAIK, this version of gitlab-runner does not support the --docker-isolation argument nor does it recognize runners[i].docker.isolation = "hyperv".
    The alternative solution to achieve this is to edit the docker daemon json configuration, located in either %userprofile%.dockerwindows-daemon.json or %programdata%dockerconfigdaemon.json.
    The entry to add is "exec-opts":["isolation=hyperv"].
    isolation=hyperv is needed to provision CPUs and memory. Request to provision CPUs and memory is ignored otherwise (in process isolation).
    Of course, without provisioning a subset of resources per docker-windows executor, the concern is that multiple docker containers can be spawned on a single host, with too many processes that overwhelm the host with excessive context-switching.

    In config.toml, I added the following:

    [[runners]]
  ...
  pre_build_script = """
$CI_PROJECT_POSIX_PATH = python -c "from pathlib import Path; >print(Path(r'$CI_PROJECT_DIR').resolve().as_posix())"
echo "> git config --global --add safe.directory >$CI_PROJECT_POSIX_PATH"
git config --global --add safe.directory $CI_PROJECT_POSIX_PATH
"""
  ...

    Python3.11 is conveniently baked into the docker image that’s specified in the .gitlab-ci.yml for the main build script to run in.$CI_PROJECT_DIR is something like c:buildsnextest-engusamagnum, all in lowercase.
    The "dubious owner" error message from Git suggests doing git config --global --add safe.directory C:/builds/nextest-eng/usa/magnum, and it turns out that this is case-sensitive, even on Windows (I am dumb for overlooking this since git-for-windows is case-sensitive for tracked paths).

    Python is used to automate the mapping of $CI_PROJECT_DIR to the exact case-sensitive path, with posix separators, that git-config suggests to use.
    In this is example, $CI_PROJECT_POSIX_PATH results in C:/builds/nextest-eng/usa/magnum.
    For hours, I was setting c:/builds/nextest-eng/usa/magnum as my safe.directory which was being ignored as a non-matching dirpath b.c. the drive letter was incorrectly lowercase.

    This might work for gitlab-runner 15.10 with the non-deprecated pre_get_sources_script hook instead (or the deprecated pre_clone_script), but if it does not use the .gitlab-ci.yml specified image and uses the gitlab-runner-helper instead, then python will not be found and it will fail.
    In the interest of time and b.c. gitlab-runner 15.10 does not offer any additional gain that I need right now, I am going to stick with gitlab-runner 14.10.1.

    Login or Signup to reply.
  2. 0

    I had this as well when using an image from mcr.microsoft.com/windows/servercore:ltsc2016 as the executor, but it turned out the reason it was failing was because I was pre-creating the builds folder in the Dockerfile:

    RUN mkdir C:buildsmy_repo
WORKDIR C:buildsmy_repo

    When I removed this from the Dockerfile, the git dubious ownership error went away.

    (The reason I was creating this folder was because I was using the build container in local testing, and wanted the exact same path setup to be present, so I needed the folder locally too. In future I’ll create it manually though.)

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search