docs: docker -> Docker
Reviewed-by: Eric Anholt <eric@anholt.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6894>
This commit is contained in:
Erik Faye-Lund
Marge Bot
parent
8a5eebd409
commit
9d34c99f39
|
|
@ -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"]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<https://gitlab.com/gitlab-org/gitlab-runner/issues/2980#note_169233611>`_).
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<https://gitlab.freedesktop.org/freedesktop/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
|
||||
|
|
|
|||
Loading…
Reference in New Issue