CODEWITHSUNDEEP
gitlabgitlab-cigitlab-ci-runner
supervacuo
supervacuo

Reputation: 9242

gitlab-runner using directory path instead of URL to clone; fails with "does not appear to be a git repository"

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?

Upvotes: 1

Views: 1770

Answers (1)

jamesidw
jamesidw

Reputation: 66

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

Upvotes: 1

Related Questions