2020-09-25 15:20:20 +02:00
parent 0894b590a4
commit 7ee8a3a2cb
7 changed files with 25 additions and 25 deletions
@@ -45,7 +45,7 @@ and some public images, and figure out how to get your boards booting.
Once you can boot your board using a custom job definition, it's time
to connect Mesa CI to it.  Install gitlab-runner and register as a
shared runner (you'll need a gitlab admin for help with this).  The
shared runner (you'll need a GitLab admin for help with this).  The
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.
@@ -78,7 +78,7 @@ access it.  You probably have a ``volumes = ["/cache"]`` already, so now it woul
Note that this token is visible to anybody that can submit MRs to
Mesa!  It is not an actual secret.  We could just bake it into the
gitlab CI yml, but this way the current method of connecting to the
GitLab CI yml, but this way the current method of connecting to the
LAVA instance is separated from the Mesa branches (particularly
relevant as we have many stable branches all using CI).
 
@@ -29,7 +29,7 @@ gitlab-runner system, since the initramfs is what contains the Mesa
testing payload.
The boards should have networking, so that we can extract the dEQP .xml
results to artifacts on gitlab.
results to artifacts on GitLab.
Requirements (servo)
--------------------
@@ -71,7 +71,7 @@ call "servo"::
Setup
-----
Each board will be registered in fd.o gitlab.  You'll want something
Each board will be registered in fd.o GitLab.  You'll want something
like this to register a fastboot board:
.. code-block:: console
@@ -91,7 +91,7 @@ like this to register a fastboot board:
For a servo board, you'll need to also volume mount the board's NFS
root dir at /nfs and TFTP kernel directory at /tftp.
The registration token has to come from a fd.o gitlab admin going to
The registration token has to come from a fd.o GitLab admin going to
https://gitlab.freedesktop.org/admin/runners
The name scheme for Google's lab is google-freedreno-boardname-n, and
 
@@ -2,7 +2,7 @@ Docker CI
=========
For llvmpipe and swrast CI, we run tests in a container containing
VK-GL-CTS, on the shared gitlab runners provided by `freedesktop
VK-GL-CTS, on the shared GitLab runners provided by `freedesktop
<http://freedesktop.org>`_
Software architecture
@@ -19,7 +19,7 @@ come up with a working MR!).
gitlab-runner is a client that polls gitlab.freedesktop.org for
available jobs, with no inbound networking requirements.  Jobs can
have tags, so we can have DUT-specific jobs that only run on runners
with that tag marked in the gitlab UI.
with that tag marked in the GitLab UI.
Since dEQP takes a long time to run, we mark the job as "parallel" at
some level, which spawns multiple jobs from one definition, and then
 
@@ -42,7 +42,7 @@ about it on ``#freedesktop`` on Freenode and tag `Daniel Stone
`Eric Anholt <https://gitlab.freedesktop.org/anholt>`__ (``anholt`` on
IRC).
The three gitlab CI systems currently integrated are:
The three GitLab CI systems currently integrated are:
.. toctree::
@@ -133,11 +133,11 @@ Mesa's CI is currently run primarily on packet.net's m1xlarge nodes
(2.2Ghz Sandybridge), with each job getting 8 cores allocated.  You
can speed up your personal CI builds (and marge-bot merges) by using a
faster personal machine as a runner.  You can find the gitlab-runner
package in debian, or use gitlab's own builds.
package in debian, or use GitLab's own builds.
To do so, follow `gitlab's instructions
To do so, follow `GitLab's instructions
<https://docs.gitlab.com/ce/ci/runners/#create-a-specific-runner>`__ to
register your personal gitlab runner in your Mesa fork.  Then, tell
register your personal GitLab runner in your Mesa fork.  Then, tell
Mesa how many jobs it should serve (``concurrent=``) and how many
cores those jobs should use (``FDO_CI_CONCURRENT=``) by editing these
lines in ``/etc/gitlab-runner/config.toml``, for example::