-
Notifications
You must be signed in to change notification settings - Fork 249
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: qltysh/qlty
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: main
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: codefreak/codeclimate
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: master
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
Can’t automatically merge.
Don’t worry, you can still create the pull request.
- 6 commits
- 5 files changed
- 2 contributors
Commits on Aug 24, 2019
-
Permit mounting via volumes-from by passing orchestrator ID
tl;dr This helps CodeClimate engines not need intimiate docker host knowledge. In contexts like self-hosted Gitlab, we sometimes have a context where we have an invoking runner like Gitlab CI running the Docker executor, which exposes the Docker socket to the running job, so that the running job may invoke its own Docker jobs on the host. Gitlab's top-level job will set up some filesystem context (/builds, mounted as a Docker volume, in the Gitlab case). Right now, Gitlab can only support CodeClimate in a Docker-in-Docker runner, because CodeClimate performs volume mounting for the individual engines via Docker's --volume flag, which mounts not the path from the invoking container, but rather a path on the docker host. This requires that the path passed to CodeClimate as the CODECLIMATE_CODE variable match the real host path, and in the Gitlab CI case, we don't want that, so we have to "hide" the host with a DinD approach. However, this means that we also don't get any layer caching between jobs, which makes running CodeClimate prohibitively expensive, as all the engines etc have to be downloaded for each job. By supporting Docker's `volumes-from` mounting option, we can instead tell the engines to inherit any mounts from the invoking orchestrator. This permits CodeClimate to allow the top-level context set up a Docker volume, bind it to the orchestrator, and then allow the orchestrator to pass that to invoked children. This sidesteps the issue of the Engines needing to know the actual host path; as long as the orchestrator's /code directory is mounted, the children can just presume to use it as-is. To accomplish this, we just a) name the top-level container, and b) pass that name via the CODECLIMATE_ORCHESTRATOR env var: docker run \ --interactive --tty --rm \ --name codeclimate_orchestrator \ --env CODECLIMATE_ORCHESTRATOR="codeclimate_orchestrator" \ --env CODECLIMATE_CODE="/code" \ --volume "$PWD":/code \ --volume /var/run/docker.sock:/var/run/docker.sock \ --volume /tmp/cc:/tmp/cc \ codeclimate/codeclimate-wrapped analyze In the bare-metal case, this doesn't change anything - we're mounting the real host path, which then gets passed to the individual children mounted on the /code mount. While not immediately pertinent to the CodeClimate PR, In Gitlab, we can invoke the Gitlab codequality image like so: script: - CONTAINER_ID=$(docker ps -q -f "label=com.gitlab.gitlab-runner.job.id=${CI_JOB_ID}") - BUILDS_VOLUME_ID=$(docker inspect $CONTAINER_ID --format '{{ range .Mounts }}{{ if eq .Destination "/builds" }}{{ .Name }}{{ end }}{{ end }}') - docker run --rm --name "codeclimate_orchestrator_${CI_JOB_ID}" --env SOURCE_CODE="/code" --env CODECLIMATE_VERSION="volumes-from" --env ORCHESTRATOR_ID="codeclimate_orchestrator_${CI_JOB_ID}" --volume /var/run/docker.sock:/var/run/docker.sock --volume "${BUILDS_VOLUME_ID}":/code codequality:orch /code ("volumes-from" is my local Docker image for the altered CodeClimage build, and "codequality:orch" is my altered Gitlab codequality image) Because this job _must_ be executed in a context that is visible to Docker, we can query Docker to get the current job's container ID, and from there get the volume ID mounted as `/builds`. We then volume mount that volume as /code, and specify /code as the "host" location of our code to be evaluated. The orchestrator will use the passed volume as /code, which is then passed onto the engine jobs, allowing the entire process to run against an ephemeral Docker volume rather than requiring a known path on the host.
Configuration menu - View commit details
-
Copy full SHA for 242e353 - Browse repository at this point
Copy the full SHA 242e353View commit details
Commits on Aug 26, 2019
-
Configuration menu - View commit details
-
Copy full SHA for c1c0b00 - Browse repository at this point
Copy the full SHA c1c0b00View commit details
Commits on Sep 18, 2019
-
Configuration menu - View commit details
-
Copy full SHA for 5ef15bf - Browse repository at this point
Copy the full SHA 5ef15bfView commit details
Commits on Nov 19, 2019
-
Configuration menu - View commit details
-
Copy full SHA for 2da8d46 - Browse repository at this point
Copy the full SHA 2da8d46View commit details -
Configuration menu - View commit details
-
Copy full SHA for 8c45f42 - Browse repository at this point
Copy the full SHA 8c45f42View commit details -
Configuration menu - View commit details
-
Copy full SHA for 5bded17 - Browse repository at this point
Copy the full SHA 5bded17View commit details
There are no files selected for viewing