openharmony/third_party_mesa3d
1
0
Fork 0
mirror of https://gitee.com/openharmony/third_party_mesa3d synced 2024-11-27 09:31:03 +00:00
Code Issues 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
Show Stats 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
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"]

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

@ -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

16
docs/ci/docker.rst
View File

@ -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.

6
docs/ci/index.rst
View File

@ -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