Lines Matching +full:test +full:- +full:ci
4 GitLab CI
5 ---------
8 We use it to test merge requests (MRs) before merging them (pre-merge testing),
9 as well as post-merge testing, for everything that hits ``main``
11 and even then the MR CI runs in the forked repository, which might have been
14 The CI runs a number of tests, from trivial build-testing to complex GPU rendering:
16 - Build testing for a number of configurations and platforms
17 - Sanity checks (``meson test``)
18 - Most drivers are also tested using several test suites, such as the
19 `Vulkan/GL/GLES conformance test suite <https://github.com/KhronosGroup/VK-GL-CTS>`__,
21 - Replay of application traces
27 tool <#running-specific-ci-jobs>`__.
29 Due to limited resources, we currently do not run the CI automatically
33 If you're interested in the details, the main configuration file is ``.gitlab-ci.yml``,
34 and it references a number of other files in ``.gitlab-ci/``.
36 If the GitLab CI doesn't seem to be running on your fork (or MRs, as they run
38 Under "CI / CD" → "General pipelines", make sure "Custom CI config path" is
39 empty (or set to the default ``.gitlab-ci.yml``), and that the
42 If you're having issues with the GitLab CI, your best bet is to ask
48 The three GitLab CI systems currently integrated are:
54 bare-metal
59 ---------------
62 Never mix disabling/re-enabling a farm with any change that can affect a job
65 When the farm starts failing for any reason (power, network, out-of-space), it needs to be disabled…
67 .. code-block:: sh
69 git mv .ci-farms{,-disabled}/$farm_name
73 .. code-block:: sh
75 git mv .ci-farms{-disabled,}/$farm_name
82 -------------------------
84 The CI replays application traces with various drivers in two different jobs. The first
85 job replays traces listed in ``src/<driver>/ci/traces-<driver>.yml`` files and if any
87 ``src/<driver>/ci/restricted-traces-<driver>.yml`` and it is allowed to fail. This second
88 job is only created when the pipeline is triggered by ``marge-bot`` or any other user that
91 A traces YAML file also includes a ``download-url`` pointing to a MinIO
98 contributors without permissions to download non-redistributable traces can be merged
101 As an aside, only maintainers of such non-redistributable traces are responsible for
103 download and test them by themselves.
106 non-redistributable traces can request permission to Daniel Stone <daniels@collabora.com>.
110 https://gitlab.freedesktop.org/freedesktop/helm-gitlab-infra/-/commit/a3cd632743019f68ac8a829267deb…
113 to be added to the rules attribute of the GitLab CI job that accesses the restricted
119 local-traces
121 Intel CI
122 --------
124 The Intel CI is not yet integrated into the GitLab CI.
126 `the Intel CI configuration repo <https://gitlab.freedesktop.org/Mesa_CI/mesa_jenkins>`__
127 if you think you or Mesa would benefit from you having access to the Intel CI).
128 Results can be seen on `mesa-ci.01.org <https://mesa-ci.01.org>`__
131 `mesa-ci-results.jf.intel.com <http://mesa-ci-results.jf.intel.com>`__.
133 The Intel CI runs a much larger array of tests, on a number of generations
138 `VK-GL-CTS <https://github.com/KhronosGroup/VK-GL-CTS>`__,
147 If you're having issues with the Intel CI, your best bet is to ask about
148 it on ``#dri-devel`` on OFTC and tag `Nico Cortes
151 .. _CI-job-user-expectations:
153 CI job user expectations
154 ------------------------
157 unrelated work by other vendors, we require that a given driver's test
159 driver had CI and failed once a week, we would be seeing someone's
163 To ensure that, driver maintainers with CI enabled should watch the Flakes panel
164 of the `CI flakes dashboard
165 <https://ci-stats-grafana.freedesktop.org/d/Ae_TLIwVk/mesa-ci-quality-false-positives?orgId=1>`__,
168 Additionally, most CI reports test-level flakes to an IRC channel, and flakes
171 ``-flakes.txt`` file for your driver.
173 Additionally, the test farm needs to be able to provide a short enough
174 turnaround time that we can get our MRs through marge-bot without the pipeline
175 backing up. As a result, we require that the test farm be able to handle a
178 this generally means that the test runtime as reported by deqp-runner should be
181 If a test farm is short the HW to provide these guarantees, consider dropping
187 .. code-block:: yaml
192 to just run 1/10th of the test list.
197 "Busy" columns. For bare-metal, a gitlab admin can look at the `runners
200 clearly have some short-runtime jobs.
202 If a HW CI farm goes offline (network dies and all CI pipelines end up
206 to the `Farm Management <#farm-management>`__ instructions.
209 ----------------
211 Mesa's CI is currently run primarily on packet.net's m1xlarge nodes
213 can speed up your personal CI builds (and marge-bot merges) by using a
214 faster personal machine as a runner. You can find the gitlab-runner
218 <https://docs.gitlab.com/ee/ci/runners/runners_scope.html#create-a-project-runner-with-a-runner-aut…
222 lines in ``/etc/gitlab-runner/config.toml``, for example:
224 .. code-block:: toml
233 --------------
235 The CI system uses Docker images extensively to cache
236 infrequently-updated build content like the CTS. The `freedesktop.org
237 CI templates
238 <https://gitlab.freedesktop.org/freedesktop/ci-templates/>`__ help us
246 not, the associated ``.gitlab-ci/containers/<jobname>.sh`` will be run
255 bump the tag on each ``git commit --amend`` to your development
264 Building locally using CI docker images
265 ---------------------------------------
268 don't personally have. If you're experiencing this with the CI
272 Pulling docker image registry.freedesktop.org/anholt/mesa/debian/android_build:2020-09-11
276 go in _build, according to ``meson-build.sh``). We're going to be
277 using the image non-interactively so we use ``run --rm $IMAGE
278 command`` instead of ``run -it $IMAGE bash`` (which you may also find
280 .gitlab-ci.yml and run the CI meson build script:
282 .. code-block:: sh
284 IMAGE=registry.freedesktop.org/anholt/mesa/debian/android_build:2020-09-11
286 …--rm -v `pwd`:/mesa -w /mesa $IMAGE env PKG_CONFIG_PATH=/usr/local/lib/aarch64-linux-android/pkgco…
291 .. code-block:: sh
293 sudo docker run --rm -v `pwd`:/mesa $IMAGE meson compile -C /mesa/_build
295 Running specific CI jobs
296 ------------------------
298 You can use ``bin/ci/ci_run_n_monitor.py`` to run specific CI jobs. It
302 See ``bin/ci/ci_run_n_monitor.py --help`` for all the options.
304 The ``--target`` argument takes a regex that you can use to select the
305 jobs names you want to run, e.g. ``--target 'zink.*'`` will run all the
315 -----------------
317 Some conformance tests require a special treatment to be maintained on GitLab CI.
326 Updating GitLab CI Linux Kernel
327 -------------------------------
329 GitLab CI usually runs a bleeding-edge kernel. The following documentation has
330 instructions on how to uprev Linux Kernel in the GitLab CI ecosystem.
338 Reusing CI scripts for other projects
339 --------------------------------------
341 The CI scripts in ``.gitlab-ci/`` can be reused for other projects, to