From 9d34c99f39af4c018eadef0cf206a688c9bdfa3b Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Mon, 28 Sep 2020 12:29:28 +0200 Subject: [PATCH] docs: docker -> Docker Reviewed-by: Eric Anholt Part-of: --- docs/ci/LAVA.rst | 8 ++++---- docs/ci/bare-metal.rst | 4 ++-- docs/ci/docker.rst | 16 ++++++++-------- docs/ci/index.rst | 6 +++--- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/ci/LAVA.rst b/docs/ci/LAVA.rst index dbb206d708f..206e1013244 100644 --- a/docs/ci/LAVA.rst +++ b/docs/ci/LAVA.rst @@ -15,7 +15,7 @@ Mesa-LAVA software architecture The gitlab-runner will run on some host that has access to the LAVA lab, with tags like "lava-mesa-boardname" to control only taking in jobs for the hardware that the LAVA lab contains. The gitlab-runner -spawns a docker container with lava-cli in it, and connects to the +spawns a Docker container with lava-cli in it, and connects to the LAVA lab using a predefined token to submit jobs under a specific device type. @@ -50,12 +50,12 @@ runner *must* have a tag (like "mesa-lava-db410c") to restrict the jobs it takes or it will grab random jobs from tasks across fd.o, and your runner isn't ready for that. -The runner will be running an ARM docker image (we haven't done any +The runner will be running an ARM Docker image (we haven't done any x86 LAVA yet, so that isn't documented). If your host for the gitlab-runner is x86, then you'll need to install qemu-user-static and the binfmt support. -The docker image will need access to the lava instance. If it's on a +The Docker image will need access to the lava instance. If it's on a public network it should be fine. If you're running the LAVA instance on localhost, you'll need to set ``network_mode="host"`` in ``/etc/gitlab-runner/config.toml`` so it can access localhost. Create a @@ -71,7 +71,7 @@ the web interface, and create an API token. Copy that into a username: gitlab-runner Add a volume mount of that ``lavacli.yaml`` to -``/etc/gitlab-runner/config.toml`` so that the docker container can +``/etc/gitlab-runner/config.toml`` so that the Docker container can access it. You probably have a ``volumes = ["/cache"]`` already, so now it would be:: volumes = ["/home/anholt/lava-config/lavacli.yaml:/root/.config/lavacli.yaml", "/cache"] diff --git a/docs/ci/bare-metal.rst b/docs/ci/bare-metal.rst index 78c6f424973..0af32b3ba44 100644 --- a/docs/ci/bare-metal.rst +++ b/docs/ci/bare-metal.rst @@ -1,7 +1,7 @@ Bare-metal CI ============= -The bare-metal scripts run on a system with gitlab-runner and docker, +The bare-metal scripts run on a system with gitlab-runner and Docker, connected to potentially multiple bare-metal boards that run tests of Mesa. Currently only "fastboot" and "ChromeOS Servo" devices are supported. @@ -120,7 +120,7 @@ required by your bare-metal script, something like:: If you want to collect the results for fastboot you need to add the following two board-specific environment variables ``BM_WEBDAV_IP`` and ``BM_WEBDAV_PORT``. -These represent the IP address of the docker host and the board specific port number +These represent the IP address of the Docker host and the board specific port number that gets used to start a nginx server. Once you've updated your runners' configs, restart with ``sudo service diff --git a/docs/ci/docker.rst b/docs/ci/docker.rst index 7f6dd101013..bca1da4c0ff 100644 --- a/docs/ci/docker.rst +++ b/docs/ci/docker.rst @@ -8,7 +8,7 @@ VK-GL-CTS, on the shared GitLab runners provided by `freedesktop Software architecture --------------------- -The docker containers are rebuilt from the debian-install.sh script +The Docker containers are rebuilt from the debian-install.sh script when DEBIAN\_TAG is changed in .gitlab-ci.yml, and debian-test-install.sh when DEBIAN\_ARM64\_TAG is changed in .gitlab-ci.yml. The resulting images are around 500MB, and are @@ -36,7 +36,7 @@ DUT requirements ---------------- In addition to the general :ref:`CI-farm-expectations`, using -docker requires: +Docker requires: * DUTs must have a stable kernel and GPU reset (if applicable). @@ -46,25 +46,25 @@ reliably reset the GPU on failure, bugs in one MR may leak into spurious failures in another MR. This would be an unacceptable impact on Mesa developers working on other drivers. -* DUTs must be able to run docker +* DUTs must be able to run Docker -The Mesa gitlab-runner based test architecture is built around docker, +The Mesa gitlab-runner based test architecture is built around Docker, so that we can cache the Debian package installation and CTS build step across multiple test runs. Since the images are large and change approximately weekly, the DUTs also need to be running some script to -prune stale docker images periodically in order to not run out of disk +prune stale Docker images periodically in order to not run out of disk space as we rev those containers (perhaps `this script `_). -Note that docker doesn't allow containers to be stored on NFS, and -doesn't allow multiple docker daemons to interact with the same +Note that Docker doesn't allow containers to be stored on NFS, and +doesn't allow multiple Docker daemons to interact with the same network block device, so you will probably need some sort of physical storage on your DUTs. * DUTs must be public By including your device in .gitlab-ci.yml, you're effectively letting -anyone on the internet run code on your device. docker containers may +anyone on the internet run code on your device. Docker containers may provide some limited protection, but how much you trust that and what you do to mitigate hostile access is up to you. diff --git a/docs/ci/index.rst b/docs/ci/index.rst index fa51e25c124..d5ec47364c0 100644 --- a/docs/ci/index.rst +++ b/docs/ci/index.rst @@ -151,13 +151,13 @@ lines in ``/etc/gitlab-runner/config.toml``, for example:: Docker caching -------------- -The CI system uses docker images extensively to cache +The CI system uses Docker images extensively to cache infrequently-updated build content like the CTS. The `freedesktop.org CI templates `_ help us manage the building of the images to reduce how frequently rebuilds happen, and trim down the images (stripping out manpages, cleaning the -apt cache, and other such common pitfalls of building docker images). +apt cache, and other such common pitfalls of building Docker images). When running a container job, the templates will look for an existing build of that image in the container registry under @@ -170,7 +170,7 @@ string related to your branch (so that if you rebase on someone else's container update from the same day, you will get a git conflict instead of silently reusing their container) -When developing a given change to your docker image, you would have to +When developing a given change to your Docker image, you would have to bump the tag on each ``git commit --amend`` to your development branch, which can get tedious. Instead, you can navigate to the `container registry