1Docker CI 2========= 3 4For llvmpipe and swrast CI, we run tests in a container containing 5VK-GL-CTS, on the shared GitLab runners provided by `freedesktop 6<http://freedesktop.org>`_ 7 8Software architecture 9--------------------- 10 11The Docker containers are rebuilt from the debian-install.sh script 12when DEBIAN\_TAG is changed in .gitlab-ci.yml, and 13debian-test-install.sh when DEBIAN\_ARM64\_TAG is changed in 14.gitlab-ci.yml. The resulting images are around 500MB, and are 15expected to change approximately weekly (though an individual 16developer working on them may produce many more images while trying to 17come up with a working MR!). 18 19gitlab-runner is a client that polls gitlab.freedesktop.org for 20available jobs, with no inbound networking requirements. Jobs can 21have tags, so we can have DUT-specific jobs that only run on runners 22with that tag marked in the GitLab UI. 23 24Since dEQP takes a long time to run, we mark the job as "parallel" at 25some level, which spawns multiple jobs from one definition, and then 26deqp-runner.sh takes the corresponding fraction of the test list for 27that job. 28 29To reduce dEQP runtime (or avoid tests with unreliable results), a 30deqp-runner.sh invocation can provide a list of tests to skip. If 31your driver is not yet conformant, you can pass a list of expected 32failures, and the job will only fail on tests that aren't listed (look 33at the job's log for which specific tests failed). 34 35DUT requirements 36---------------- 37 38In addition to the general :ref:`CI-farm-expectations`, using 39Docker requires: 40 41* DUTs must have a stable kernel and GPU reset (if applicable). 42 43If the system goes down during a test run, that job will eventually 44time out and fail (default 1 hour). However, if the kernel can't 45reliably reset the GPU on failure, bugs in one MR may leak into 46spurious failures in another MR. This would be an unacceptable impact 47on Mesa developers working on other drivers. 48 49* DUTs must be able to run Docker 50 51The Mesa gitlab-runner based test architecture is built around Docker, 52so that we can cache the Debian package installation and CTS build 53step across multiple test runs. Since the images are large and change 54approximately weekly, the DUTs also need to be running some script to 55prune stale Docker images periodically in order to not run out of disk 56space as we rev those containers (perhaps `this script 57<https://gitlab.com/gitlab-org/gitlab-runner/issues/2980#note_169233611>`_). 58 59Note that Docker doesn't allow containers to be stored on NFS, and 60doesn't allow multiple Docker daemons to interact with the same 61network block device, so you will probably need some sort of physical 62storage on your DUTs. 63 64* DUTs must be public 65 66By including your device in .gitlab-ci.yml, you're effectively letting 67anyone on the internet run code on your device. Docker containers may 68provide some limited protection, but how much you trust that and what 69you do to mitigate hostile access is up to you. 70 71* DUTs must expose the dri device nodes to the containers. 72 73Obviously, to get access to the HW, we need to pass the render node 74through. This is done by adding ``devices = ["/dev/dri"]`` to the 75``runners.docker`` section of /etc/gitlab-runner/config.toml. 76