Consider mounting the config.json files and/or propagating DOCKER_CONFIG inside the run.sh script.
We have a customer (internal) that wants to use Dependency Proxy in the Code Quality job to workaround the Dockerhub pull rate limit.
At first, I tried modifying the code_quality
job, but I realized that it's not enough as we are running another set of docker run
commands inside run.sh
. Here is an example:
docker run \
--env CODECLIMATE_CODE="$SOURCE_CODE" \
--env CODECLIMATE_DEBUG="$CODECLIMATE_DEBUG" \
--env CODECLIMATE_PREFIX="$CODECLIMATE_PREFIX" \
--env CONTAINER_TIMEOUT_SECONDS="$CONTAINER_TIMEOUT_SECONDS" \
--volume "$SOURCE_CODE":/code \
--volume /tmp/cc:/tmp/cc \
--volume /var/run/docker.sock:/var/run/docker.sock \
"${CODECLIMATE_FULL_IMAGE}" engines:install > /dev/null
I believe codeclimate itself uses docker pull
to "install" these engines. If we didn't modify this to also propagate the config.json
file and the DOCKER_CONFIG
(this is required if we mount config.json
on a different location), codelimate won't be able to pull these images.
Our Code Quality job goes deep into "nested" containers (although it's not really nested as we are just mounting docker.sock
):
- The job itself is already a container which uses the image
docker:19.03.12
. -> First container - Inside the job, we run
docker run
(which mounts/var/run/docker.sock
) which runs the imageregistry.gitlab.com/gitlab-org/ci-cd/codequality:0.85.24
-> Second container - Inside the container, we run
run.sh
. This script calls another set ofdocker run
(which mounts/var/run/docker.sock
) commands, which runs the image$CODECLIMATE_IMAGE:$CODECLIMATE_VERSION
-> Third container - There is a possibility of a Fourth nested container, if Codelimate runs another set of containers to run the scan.
We will need to propagate that with each docker run
command.