Lines Matching +full:bare +full:- +full:cross +full:- +full:build
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 ``master``
14 The CI runs a number of tests, from trivial build-testing to complex GPU rendering:
16 - Build testing for a number of build systems, configurations and platforms
17 - Sanity checks (``meson test`` & ``scons check``)
18 - Some drivers (softpipe, llvmpipe, freedreno and panfrost) are also tested
19 using `VK-GL-CTS <https://github.com/KhronosGroup/VK-GL-CTS>`__
20 - Replay of application traces
30 If you're interested in the details, the main configuration file is ``.gitlab-ci.yml``,
31 and it references a number of other files in ``.gitlab-ci/``.
36 empty (or set to the default ``.gitlab-ci.yml``), and that the
51 bare-metal
56 --------
62 Results can be seen on `mesa-ci.01.org <https://mesa-ci.01.org>`__
65 `mesa-ci-results.jf.intel.com <http://mesa-ci-results.jf.intel.com>`__.
72 `VK-GL-CTS <https://github.com/KhronosGroup/VK-GL-CTS>`__,
82 it on ``#dri-devel`` on Freenode and tag `Clayton Craft
87 .. _CI-farm-expectations:
90 --------------------
100 turnaround time that we can get our MRs through marge-bot without the
103 (to compare, the build stage is about 10 minutes).
107 ``VK-GL-CTS/scripts/log/bottleneck_report.py`` can help you find what
111 .. code-block:: yaml
125 report to mesa-dev@lists.freedesktop.org after the fact explaining
130 ----------------
134 can speed up your personal CI builds (and marge-bot merges) by using a
135 faster personal machine as a runner. You can find the gitlab-runner
139 <https://docs.gitlab.com/ce/ci/runners/#create-a-specific-runner>`__ to
143 lines in ``/etc/gitlab-runner/config.toml``, for example::
152 --------------
155 infrequently-updated build content like the CTS. The `freedesktop.org
157 <https://gitlab.freedesktop.org/freedesktop/ci-templates/>`_ help us
163 build of that image in the container registry under
165 not, the associated `.gitlab-ci/containers/<jobname>.sh`` will be run
166 to build it. So, when developing any change to container build
174 bump the tag on each ``git commit --amend`` to your development
184 ---------------------------------------
186 It can be frustrating to debug build failures on an environment you
188 builds, you can use Docker to use their build environment locally. Go
191 Pulling docker image registry.freedesktop.org/anholt/mesa/debian/android_build:2020-09-11
194 Docker container uses, so they'll share everything (their build will
195 go in _build, according to ``meson-build.sh``). We're going to be
196 using the image non-interactively so we use ``run --rm $IMAGE
197 command`` instead of ``run -it $IMAGE bash`` (which you may also find
198 useful for debug). Extract your build setup variables from
199 .gitlab-ci.yml and run the CI meson build script:
201 .. code-block:: console
203 IMAGE=registry.freedesktop.org/anholt/mesa/debian/android_build:2020-09-11
205 …--rm -v `pwd`:/mesa -w /mesa $IMAGE env PKG_CONFIG_PATH=/usr/local/lib/aarch64-linux-android/pkgco…
207 All you have left over from the build is its output, and a _build
208 directory. You can hack on mesa and iterate testing the build with:
210 .. code-block:: console
212 sudo docker run --rm -v `pwd`:/mesa $IMAGE ninja -C /mesa/_build