Commit 7ee8a3a2 authored by Erik Faye-Lund 's avatar Erik Faye-Lund 💬 Committed by Marge Bot
Browse files

docs: gitlab -> GitLab


Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric@engestrom.ch>
Part-of: <!6864>
parent 0894b590
......@@ -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::
......
......@@ -71,11 +71,11 @@ Commits nominated for the active branch are picked as based on the
section.
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.
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 picked from ..." to the commit message):
......@@ -92,7 +92,7 @@ Following developers have requested permanent exception
- *Ilia Mirkin*
- *AMD team*
The gitlab CI must pass.
The GitLab CI must pass.
For Windows related changes, the main contact point is Brian Paul. Jose
Fonseca can also help as a fallback contact.
......@@ -191,7 +191,7 @@ To setup the branchpoint:
git push origin X.Y-branchpoint X.Y
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.
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
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
......
......@@ -47,7 +47,7 @@ To get the Mesa sources anonymously (read-only):
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:
#. Subscribe to the
......@@ -56,7 +56,7 @@ please follow this procedure:
#. Start contributing to the project by :doc:`submitting
patches <submittingpatches>`. Specifically,
- Use `gitlab <https://gitlab.freedesktop.org/>`__ to create your
- Use `GitLab <https://gitlab.freedesktop.org/>`__ to create your
merge requests.
- Wait for someone to review the code and give you a ``Reviewed-by``
statement.
......@@ -67,7 +67,7 @@ please follow this procedure:
a dozen or so patches accepted, a maintainer may use their discretion
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
......
......@@ -52,7 +52,7 @@ Patch formatting
platform.
- 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:
::
......@@ -225,7 +225,7 @@ Reviewing Patches
To participate in code review, you can monitor the GitLab Mesa `Merge
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.
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
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:
::
`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.
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.
- By adding the ``Cc: mesa-stable`` tag in the commit message as described above.
- 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
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
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
staging/year.quarter branch, not on the year.quarter branch, per the
stable branch policy. Assigning the MR to release maintainer for said
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment