OpenHarmony/third_party_mesa3d
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: docker -> Docker

Browse Source 
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
2020-09-28 12:29:28 +02:00
committed by Marge Bot
parent 8a5eebd409
commit 9d34c99f39
4 changed files with 17 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/ci/LAVA.rst
View File

@@ -15,7 +15,7 @@ Mesa-LAVA software architecture
The gitlab-runner will run on some host that has access to the LAVA 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 lab, with tags like "lava-mesa-boardname" to control only taking in
jobs for the hardware that the LAVA lab contains. The gitlab-runner 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 LAVA lab using a predefined token to submit jobs under a specific
device type. 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 jobs it takes or it will grab random jobs from tasks across fd.o, and
your runner isn't ready for that. 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 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 gitlab-runner is x86, then you'll need to install qemu-user-static and
the binfmt support. 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 public network it should be fine. If you're running the LAVA instance
on localhost, you'll need to set ``network_mode="host"`` in on localhost, you'll need to set ``network_mode="host"`` in
``/etc/gitlab-runner/config.toml`` so it can access localhost. Create a ``/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 username: gitlab-runner
Add a volume mount of that ``lavacli.yaml`` to 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:: 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"] volumes = ["/home/anholt/lava-config/lavacli.yaml:/root/.config/lavacli.yaml", "/cache"]

4
docs/ci/bare-metal.rst
View File

@@ -1,7 +1,7 @@
Bare-metal CI 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 connected to potentially multiple bare-metal boards that run tests of
Mesa. Currently only "fastboot" and "ChromeOS Servo" devices are Mesa. Currently only "fastboot" and "ChromeOS Servo" devices are
supported. 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 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``. 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. that gets used to start a nginx server.
Once you've updated your runners' configs, restart with ``sudo service Once you've updated your runners' configs, restart with ``sudo service

16
docs/ci/docker.rst
View File

@@ -8,7 +8,7 @@ VK-GL-CTS, on the shared GitLab runners provided by `freedesktop
Software architecture 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 when DEBIAN\_TAG is changed in .gitlab-ci.yml, and
debian-test-install.sh when DEBIAN\_ARM64\_TAG is changed in debian-test-install.sh when DEBIAN\_ARM64\_TAG is changed in
.gitlab-ci.yml. The resulting images are around 500MB, and are .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 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). * 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 spurious failures in another MR. This would be an unacceptable impact
on Mesa developers working on other drivers. 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 so that we can cache the Debian package installation and CTS build
step across multiple test runs. Since the images are large and change step across multiple test runs. Since the images are large and change
approximately weekly, the DUTs also need to be running some script to 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 space as we rev those containers (perhaps `this script
<https://gitlab.com/gitlab-org/gitlab-runner/issues/2980#note_169233611>`_). <https://gitlab.com/gitlab-org/gitlab-runner/issues/2980#note_169233611>`_).
Note that docker doesn't allow containers to be stored on NFS, and Note that Docker doesn't allow containers to be stored on NFS, and
doesn't allow multiple docker daemons to interact with the same doesn't allow multiple Docker daemons to interact with the same
network block device, so you will probably need some sort of physical network block device, so you will probably need some sort of physical
storage on your DUTs. storage on your DUTs.
* DUTs must be public * DUTs must be public
By including your device in .gitlab-ci.yml, you're effectively letting 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 provide some limited protection, but how much you trust that and what
you do to mitigate hostile access is up to you. you do to mitigate hostile access is up to you.

6
docs/ci/index.rst
View File

@@ -151,13 +151,13 @@ lines in ``/etc/gitlab-runner/config.toml``, for example::
Docker caching 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 infrequently-updated build content like the CTS. The `freedesktop.org
CI templates CI templates
<https://gitlab.freedesktop.org/freedesktop/ci-templates/>`_ help us <https://gitlab.freedesktop.org/freedesktop/ci-templates/>`_ help us
manage the building of the images to reduce how frequently rebuilds manage the building of the images to reduce how frequently rebuilds
happen, and trim down the images (stripping out manpages, cleaning the 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 When running a container job, the templates will look for an existing
build of that image in the container registry under 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 container update from the same day, you will get a git conflict
instead of silently reusing their container) 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 bump the tag on each ``git commit --amend`` to your development
branch, which can get tedious. Instead, you can navigate to the branch, which can get tedious. Instead, you can navigate to the
`container registry `container registry