'With GitLab CI/CD, how to have code cloned in a container by user:group 'java:java', instead of 'root?

In a GitLab repo, I have a Dockerfile with the following lines,

FROM python:alpine
RUN addgroup -S java
RUN adduser -s /bin/bash -S -G java java
USER java
WORKDIR /home/java

so that when the image is instantiated (container running), it will run as user ‘java’

When GitLab CI/CD clones the project code however, it is owned by root in directory /home/java

This is unexpected behavior, I would expect it to be owned by user ‘java’

How do I get the code to be cloned by user ‘java’, and owned (user:group), by user:group ‘java:java’?

Solution 1:^[1]

GitLab CI clones the code outside your job container using the gitlab/gitlab-runner-helper docker image (repository for runner helper). If you're running your own executor you can override what helper image is used for cloning the repository to one that clones using a java user though you'd have to make sure that the user/group ID matched in the two containers to prevent issues. This would also mean you're maintaining your own extended runner helper and you couldn't use the shared runners hosted by GitLab.

You have an alternate possible approach though I wouldn't recommend it: You could set your git strategy to not clone your repo, then clone it in a before_script: action within your job container, which would cause it to clone with your java user. However this will only clone the repository within that one job, so you'd have to repeat yourself across every job which would violate DRY all over the place.

Generally though, I'd agree with David that having the code owned by root is fine in this case unless you have a specific reason to change

Solution 2:^[2]

Projects in GitLab are cloned with the GitLab runner helper image, which is using root. It will also use umask 0000 to avoid permission issues, if data is cached.

See this GitLab issue for more details.

To fix your issue, add an environment variable: FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR=true

This will disable the umask usage and the runner tries to get UID and GID from the image of the build container.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution	Source
Solution 1	Patrick
Solution 2	Saz

'With GitLab CI/CD, how to have code cloned in a container by user:group 'java:java', instead of 'root?

Solution 1:[1]

Solution 2:[2]

Sources

Related Questions

Solution 1:^[1]

Solution 2:^[2]