ci: Briefly document the CI setup.

This commit is contained in:
Giovanni Mascellani 2023-08-30 22:09:39 +02:00 committed by Alexandre Julliard
parent 229a34b93c
commit 367cf10cdc
Notes: Alexandre Julliard 2023-08-31 22:48:11 +02:00
Approved-by: Henri Verbeet (@hverbeet)
Approved-by: Alexandre Julliard (@julliard)
Merge-Request: https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/318
2 changed files with 53 additions and 0 deletions

11
README
View File

@ -82,3 +82,14 @@ commas or semicolons.
conditions in tests.
* VKD3D_TEST_BUG - set to 0 to disable bug_if() conditions in tests.
================
Developing vkd3d
================
Development of vkd3d happens on the Wine GitLab instance
(https://gitlab.winehq.org/wine/vkd3d/). Contributors are encouraged
to submit their patches using the merge request tool.
Each merge request is automatically tested with the GitLab CI
system. See gitlab/README in the Git tree for more details.

42
gitlab/README Normal file
View File

@ -0,0 +1,42 @@
=====================
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 x86-64, with two different Vulkan drivers
(both from Mesa): llvmpipe (a software implementation) and RADV (a
hardware implementation backed by an AMD GPU). 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.