testuser needs to be root

Hi - since 0.7.1 release of gitlab-ci-multi-runner checkout is done in a different container. The checkout user is root, so everything on this cached/shared checkout volume is owned by root, which blocks building/testing on docker images which use a different user to build with, because you get a permission denied error when writing to directories owned by root

Any idea how to change permission on the checkout volume?

@widerin Maybe we can play with the umask, so the permission will be 777 and 666?

umask 000
git config --global core.sharedRepository true

yes, that would definitely solve the issue.

I am running into this issue too, using a docker ci runner image that drops privileges.

Could you think of a way to use the current user for git checkouts, e.g. if the last USER command in the docker file is USER cirunner then just execute any command (including git checkouts / clones / updates) within the runner image as user cirunner?

I did not dig deeper into how (and where) the runner executes the git checkout -- presumably it is done within the gitlab-ci-multi-runner and not within the docker image run by the executor. If so, could you change this and move the git checkout into the executed image?

That would be a 'clean' solution imho, because that way the builder of the executed image could decide under which permissions / users the build is executed.

@istr

Previously the git clone were executed by user provided image. The problem was that most of images doesn't have git installed. Right now the gitlab/gitlab-runner:build is used to run git clone in separate container.

We can hack this Dockerfile to always clone with 777/666: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/dockerfiles/build/Dockerfile

@ayufan Ok, got the point.

But you need to execute stuff in the target image anyway. Why not prepend a command that copies a static version of git into the target image's /bin path? That way any image would fall back to this git version. Most images would even fall back to this if there's no git installed and would use the git version installed in the image (due to common /usr/bin over /bin preference).

It seems to be easy to compile a static git binary and I bet that it would even be smaller/faster to include a static git binary than launching a separate container.

Of course you would need a set of static binaries to support non x86 platforms, but the current setup (using an x86 Alpine image) does not support other platforms anyway, so this would not even be a regression wrt portability.

@istr

I don't like this. This puts more maintenance hurdle on GitLab Runner.

Worth to mention that currently build image also restores the cached files. In the near future it will also restore artifacts from other stages. In the future it may get privileges to do docker build. It will be hard to reimplement this in your own image.

@ayufan Good. Thanks for clarification. :-)

In that case using world-writable access for the repository under test seems to be the best option.

BTW do you see any progress on virtualbox support?

can't you copy the cloned repository from the location where gitlab/gitlab-runner:build left it to a location that is writable by the user that runs the test image?

e.g. /var/tmp/builds/...

@terceiro Yes, there are lots of workarounds, to be honest. :-)

In fact, building to a sub-location of the repository at all could be considered "bad practice" and having a "read-only" copy is not such a bad idea to start with.

An rsync'ed copy within the image could be an idea to not completely lose the advantage of cached / incrementally updated checkouts.

@istr @terceiro i don't want to update all 250 .gitlab-ci.yml files i have already in place. Another possibility would be to allow override of build image, so advanced users can adjust.

@widerin I'll fix that in :build image

Milestone changed to v1.0

Reassigned to @ayufan

mentioned in merge request !57 (merged)

@ayufan just in this moment i filed a merge request, see !57 (merged)

allowing override of the build image seems to be the best option indeed

Status changed to closed by commit e4d2ee0a3875cda9667034e7b1238eb97e49e04e