gitlab-runner 使用目录路径而不是 URL 来克隆； 失败并显示“似乎不是 git 存储库”

Question

I am trying to run my GitLab CI tests locally, to speed up developing CI.

I installed gitlab-runner locally (on my GNU/Linux box) following these instructions .

Now, when I run sudo gitlab-runner exec docker test , I get:

sudo gitlab-runner exec docker test
Runtime platform                                    arch=amd64 os=linux pid=7133 revision=0e5417a3 version=12.0.1
Running with gitlab-runner 12.0.1 (0e5417a3)
Using Docker executor with image joyzoursky/python-chromedriver:2.7 ...
Pulling docker image joyzoursky/python-chromedriver:2.7 ...
Using docker image sha256:f593ebe67d0c75eb8e3d663412c8fc80df70bd08e835d7a64ba6afa21b1c2d8a for joyzoursky/python-chromedriver:2.7 ...
Running on runner--project-0-concurrent-0 via hostname...
Fetching changes...
Initialized empty Git repository in /builds/project-0/.git/
Created fresh repository.
fatal: '/home/USER/path/to/repo' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
ERROR: Job failed: exit code 1
FATAL: exit code 1                                 

( /home/USER/path/to/repo is the actual path to my working directory containing .gitlab-ci.yml , and my project code)

So, it looks like gitlab-runner is trying to use the directory path as a git clone URL, which obviously won't work.

I tried specifying --clone-url= , but I can't understand what part of the full project URL (either in the main git repo, or the gitlab mirror) I should be using.

Any clues?

Answer 1

If you are on Fedora and have SELinux enabled; try setting that to permissive:

sudo setenforce 0

SELinux blocks any activity that isn't allowed by some existing policy. The GitLab runner is basically a docker container trying to access files on the host machine, so that gets blocked...which leads the runner to report that you don't have a valid repository at (an error saying it can't read the files would have made more sense but we don't live in a perfect world)

The lazy fix is to make SELinux blanket permit the activity, if you don't do this sort of thing often enough to warrant a policy change for example.

The more security conscious will prefer to edit the policy instead. Figure out some unique identifier in the denial error, then create a new policy to allow it

sudo grep <needle> /var/log/audit/audit.log | audit2allow -M gitlab
sudo semodule -i gitlab.pp