vkd3d/gitlab
Giovanni Mascellani 3113f167ba ci: Do not drop artifacts after 1 day.
There is no point in using such a short timeout. We trust the GitLab
instance to already have a sensible default.
2023-09-14 20:28:49 +02:00
..
build-linux ci: Execute the tests. 2023-08-31 22:07:21 +02:00
build-mac ci: Run the tests on macOS. 2023-09-14 20:28:47 +02:00
build.yml ci: Do not drop artifacts after 1 day. 2023-09-14 20:28:49 +02:00
image.docker ci: Execute CI also an a runner with an AMD GPU. 2023-08-31 22:07:16 +02:00
image.yml ci: Introduce a CI pipeline for GitLab. 2023-08-29 22:07:56 +02:00
patch_moltenvk_icd.sh ci: Run the tests on macOS. 2023-09-14 20:28:47 +02:00
README ci: Run the tests on macOS. 2023-09-14 20:28:47 +02:00

=====================
vkd3d testing scripts
=====================

These scripts are used by the GitLab CI feature to automatically run
the vkd3d tests on each merge request.

The CI target build-image, in the file image.yml, builds a Docker
image based on Debian bookworm with all the packages required for
testing, and uploads it to the GitLab container registry. The Docker
script is in the file image.docker.

The file build.yml contains the actual testing targets. Currently
vkd3d is tested on Linux, on x86-64 and i386, each architecture with
two different Vulkan drivers (both from Mesa): llvmpipe (a software
implementation) and RADV (a hardware implementation backed by an AMD
GPU); and on macOS, on Intel, using MoltenVK as Vulkan driver. The
testing logs are available as CI artifacts.

Some custom runner configuration is required in order to run the tests
on an AMD GPU. Specifically, a runner tagged with `amd-gpu' must be
available with the following features:

 * of course a sufficiently recent AMD GPU must be available to the
   host;

 * the host kernel must have the appropriate driver and firmware
   installed;

 * the runner must forward the DRI nodes to the guest; this can be
   configured by adding the line

     devices = ["/dev/dri"]

   to the relevant [runners.docker] section in the config.toml file;

 * the DRI render nodes must be readable and writable by GID 800,
   either because they belong to that group (e.g. because the group
   `render', which typically owns those files, has GID 800) or via a
   FS ACL; such stipulation is needed because in Debian group `render'
   is created dynamically, therefore has no predictable GID: the use
   of a fixed GID enables the guest system to be set up so that the
   user running the tests can access the render nodes.

A runner on an Intel macOS system tagged with `mac' must also be
available to run the macOS tests. Unfortunately a system like Docker
is not available in this case to provide an isolated standard
environment for running the tests. All the software required to
compile and run the tests will therefore have to be installed directly
on the host system. Complete instructions to setup the macOS are
currently not available.