Lines Matching +full:debian +full:- +full:build +full:- +full:testing
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``
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>`__.
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/``.
39 empty (or set to the default ``.gitlab-ci.yml``), and that the
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 -------------------------
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
106 non-redistributable traces can request permission to Daniel Stone <daniels@collabora.com>.
110 https://gitlab.freedesktop.org/freedesktop/helm-gitlab-infra/-/commit/a3cd632743019f68ac8a829267deb…
119 local-traces
122 --------
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>`__.
138 `VK-GL-CTS <https://github.com/KhronosGroup/VK-GL-CTS>`__,
148 it on ``#dri-devel`` on OFTC and tag `Nico Cortes
151 .. _CI-job-user-expectations:
154 ------------------------
156 To make sure that testing of one vendor's drivers doesn't block
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.
174 turnaround time that we can get our MRs through marge-bot without the pipeline
176 whole pipeline's worth of jobs in less than 15 minutes (to compare, the build
178 this generally means that the test runtime as reported by deqp-runner should be
187 .. code-block:: yaml
197 "Busy" columns. For bare-metal, a gitlab admin can look at the `runners
200 clearly have some short-runtime jobs.
206 to the `Farm Management <#farm-management>`__ instructions.
209 ----------------
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
215 package in Debian, or use GitLab's own builds.
218 …cs.gitlab.com/ee/ci/runners/runners_scope.html#create-a-project-runner-with-a-runner-authenticatio…
222 lines in ``/etc/gitlab-runner/config.toml``, for example:
224 .. code-block:: toml
233 --------------
236 infrequently-updated build content like the CTS. The `freedesktop.org
238 <https://gitlab.freedesktop.org/freedesktop/ci-templates/>`__ help us
244 build of that image in the container registry under
246 not, the associated ``.gitlab-ci/containers/<jobname>.sh`` will be run
247 to build it. So, when developing any change to container build
255 bump the tag on each ``git commit --amend`` to your development
265 ---------------------------------------
267 It can be frustrating to debug build failures on an environment you
269 builds, you can use Docker to use their build environment locally. Go
272 Pulling docker image registry.freedesktop.org/anholt/mesa/debian/android_build:2020-09-11
275 Docker container uses, so they'll share everything (their build will
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
279 useful for debug). Extract your build setup variables from
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…
288 All you have left over from the build is its output, and a _build
289 directory. You can hack on mesa and iterate testing the build with:
291 .. code-block:: sh
293 sudo docker run --rm -v `pwd`:/mesa $IMAGE meson compile -C /mesa/_build
296 ------------------------
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 -----------------
327 -------------------------------
329 GitLab CI usually runs a bleeding-edge kernel. The following documentation has
339 --------------------------------------
341 The CI scripts in ``.gitlab-ci/`` can be reused for other projects, to
347 Define extra Debian packages to be installed in the container.