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
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
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
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.
						
							
						
						
							
						
						
						
@@ -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
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
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
LAVA instance is separated from the Mesa branches (particularly
relevant as we have many stable branches all using CI).
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.
testing payload.
The boards should have networking, so that we can extract the dEQP .xml
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)
Requirements (servo)
--------------------
--------------------
						
							
						
						
							
						
						
						
@@ -71,7 +71,7 @@ call "servo"::
Setup
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:
like this to register a fastboot board:
.. code-block:: console
.. 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
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.
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
https://gitlab.freedesktop.org/admin/runners
The name scheme for Google's lab is google-freedreno-boardname-n, and
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
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>`_
<http://freedesktop.org>`_
Software architecture
Software architecture
						
						
						
							
						
						
@@ -19,7 +19,7 @@ come up with a working MR!).
gitlab-runner is a client that polls gitlab.freedesktop.org for
gitlab-runner is a client that polls gitlab.freedesktop.org for
available jobs, with no inbound networking requirements.  Jobs can
available jobs, with no inbound networking requirements.  Jobs can
have tags, so we can have DUT-specific jobs that only run on runners
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
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
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
`Eric Anholt <https://gitlab.freedesktop.org/anholt>`__ (``anholt`` on
IRC).
IRC).
The three gitlab CI systems currently integrated are:
The three GitLab CI systems currently integrated are:
.. toctree::
.. 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
(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
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
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
<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
Mesa how many jobs it should serve (``concurrent=``) and how many
cores those jobs should use (``FDO_CI_CONCURRENT=``) by editing these
cores those jobs should use (``FDO_CI_CONCURRENT=``) by editing these
lines in ``/etc/gitlab-runner/config.toml``, for example::
lines in ``/etc/gitlab-runner/config.toml``, for example::
						
							
						
						
						
						
 
						
						
							
						
						
						
@@ -71,11 +71,11 @@ Commits nominated for the active branch are picked as based on the
section.
section.
Nominations happen via special tags in the commit messages, and via
Nominations happen via special tags in the commit messages, and via
gitlab merge requests against the staging branches. There are special
GitLab merge requests against the staging branches. There are special
scripts used to read the tags.
scripts used to read the tags.
The maintainer should watch or be in contact with the Intel CI team, as
The maintainer should watch or be in contact with the Intel CI team, as
well as watch the gitlab CI for regressions.
well as watch the GitLab CI for regressions.
Cherry picking should be done with the '-x' switch (to automatically add
Cherry picking should be done with the '-x' switch (to automatically add
"cherry picked from ..." to the commit message):
"cherry picked from ..." to the commit message):
						
						
						
							
						
						
@@ -92,7 +92,7 @@ Following developers have requested permanent exception
-  *Ilia Mirkin*
-  *Ilia Mirkin*
-  *AMD team*
-  *AMD team*
The gitlab CI must pass.
The GitLab CI must pass.
For Windows related changes, the main contact point is Brian Paul. Jose
For Windows related changes, the main contact point is Brian Paul. Jose
Fonseca can also help as a fallback contact.
Fonseca can also help as a fallback contact.
						
							
						
						
							
						
						
						
@@ -191,7 +191,7 @@ To setup the branchpoint:
   git push origin X.Y-branchpoint X.Y
   git push origin X.Y-branchpoint X.Y
Now go to
Now go to
`gitlab <https://gitlab.freedesktop.org/mesa/mesa/-/milestones>`__ and
`GitLab <https://gitlab.freedesktop.org/mesa/mesa/-/milestones>`__ and
add the new Mesa version X.Y.
add the new Mesa version X.Y.
Check that there are no distribution breaking changes and revert them if
Check that there are no distribution breaking changes and revert them if
						
							
						
						
							
						
						
						
@@ -326,7 +326,7 @@ Use the generated template during the releasing process.
Again, pay attention to add a note to warn about a final release in a
Again, pay attention to add a note to warn about a final release in a
series, if that is the case.
series, if that is the case.
Update gitlab issues
Update GitLab issues
--------------------
--------------------
Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.rst
Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.rst
						
							
						
						
						
						
 
						
						
							
						
						
						
@@ -47,7 +47,7 @@ To get the Mesa sources anonymously (read-only):
Developer git Access
Developer git Access
--------------------
--------------------
If you wish to become a Mesa developer with gitlab merge privilege,
If you wish to become a Mesa developer with GitLab merge privilege,
please follow this procedure:
please follow this procedure:
#. Subscribe to the
#. Subscribe to the
						
						
						
							
						
						
@@ -56,7 +56,7 @@ please follow this procedure:
#. Start contributing to the project by :doc:`submitting
#. Start contributing to the project by :doc:`submitting
   patches <submittingpatches>`. Specifically,
   patches <submittingpatches>`. Specifically,
   -  Use `gitlab <https://gitlab.freedesktop.org/>`__ to create your
   -  Use `GitLab <https://gitlab.freedesktop.org/>`__ to create your
      merge requests.
      merge requests.
   -  Wait for someone to review the code and give you a ``Reviewed-by``
   -  Wait for someone to review the code and give you a ``Reviewed-by``
      statement.
      statement.
						
						
						
							
						
						
@@ -67,7 +67,7 @@ please follow this procedure:
   a dozen or so patches accepted, a maintainer may use their discretion
   a dozen or so patches accepted, a maintainer may use their discretion
   to give you access to merge your own code.
   to give you access to merge your own code.
Pushing code to your gitlab account via HTTPS
Pushing code to your GitLab account via HTTPS
---------------------------------------------
---------------------------------------------
Useful for people behind strict proxies
Useful for people behind strict proxies
						
							
						
						
						
						
 
						
						
							
						
						
						
@@ -52,7 +52,7 @@ Patch formatting
      platform.
      platform.
-  A "Signed-off-by:" line is not required, but not discouraged either.
-  A "Signed-off-by:" line is not required, but not discouraged either.
-  If a patch addresses an issue in gitlab, use the Closes: tag For
-  If a patch addresses an issue in GitLab, use the Closes: tag For
   example:
   example:
   ::
   ::
						
							
						
						
							
						
						
						
@@ -225,7 +225,7 @@ Reviewing Patches
To participate in code review, you can monitor the GitLab Mesa `Merge
To participate in code review, you can monitor the GitLab Mesa `Merge
Requests <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests>`__
Requests <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests>`__
page, and/or register for notifications in your gitlab settings.
page, and/or register for notifications in your GitLab settings.
When you've reviewed a patch, please be unambiguous about your review.
When you've reviewed a patch, please be unambiguous about your review.
That is, state either
That is, state either
						
							
						
						
							
						
						
						
@@ -254,14 +254,14 @@ the issues are resolved first.
These Reviewed-by, Acked-by, and Tested-by tags should also be amended
These Reviewed-by, Acked-by, and Tested-by tags should also be amended
into commits in a MR before it is merged.
into commits in a MR before it is merged.
When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR,
When providing a Reviewed-by, Acked-by, or Tested-by tag in a GitLab MR,
enclose the tag in backticks:
enclose the tag in backticks:
::
::
   `Reviewed-by: Joe Hacker <jhacker@example.com>`
   `Reviewed-by: Joe Hacker <jhacker@example.com>`
This is the markdown format for literal, and will prevent gitlab from
This is the markdown format for literal, and will prevent GitLab from
hiding the < and > symbols.
hiding the < and > symbols.
Review by non-experts is encouraged. Understanding how someone else goes
Review by non-experts is encouraged. Understanding how someone else goes
						
						
						
							
						
						
@@ -280,7 +280,7 @@ branch and release. In order or preference:
  a specific commit.
  a specific commit.
- By adding the ``Cc: mesa-stable`` tag in the commit message as described above.
- By adding the ``Cc: mesa-stable`` tag in the commit message as described above.
- By submitting a merge request against the ``staging/year.quarter``
- By submitting a merge request against the ``staging/year.quarter``
  branch on gitlab.
  branch on GitLab.
Please **DO NOT** send patches to mesa-stable@lists.freedesktop.org, it
Please **DO NOT** send patches to mesa-stable@lists.freedesktop.org, it
is not monitored actively and is a historical artifact.
is not monitored actively and is a historical artifact.
						
							
						
						
							
						
						
						
@@ -354,7 +354,7 @@ de-nominate the patch.
For patches that either need to be nominated after they've landed in
For patches that either need to be nominated after they've landed in
master, or that are known ahead of time to not not apply cleanly to a
master, or that are known ahead of time to not not apply cleanly to a
stable branch (such as due to a rename), using a gitlab MR is most
stable branch (such as due to a rename), using a GitLab MR is most
appropriate. The MR should be based on and target the
appropriate. The MR should be based on and target the
staging/year.quarter branch, not on the year.quarter branch, per the
staging/year.quarter branch, not on the year.quarter branch, per the
stable branch policy. Assigning the MR to release maintainer for said
stable branch policy. Assigning the MR to release maintainer for said