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):

1. The job itself is already a container which uses the image docker:19.03.12. -> First container
2. Inside the job, we run docker run (which mounts /var/run/docker.sock) which runs the image registry.gitlab.com/gitlab-org/ci-cd/codequality:0.85.24 -> Second container
3. Inside the container, we run run.sh. This script calls another set of docker run (which mounts /var/run/docker.sock) commands, which runs the image $CODECLIMATE_IMAGE:$CODECLIMATE_VERSION -> Third container
4. 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.