We need to use a later version of Meson than is currently available
in the Alpine repository. Use the existing `install-meson.sh` to fetch
the appropriate version from PyPI.
This requires that we explicitly install a Ninja impl on Alpine -
Samurai is the preferred impl and by using this we do not need
to prefix `PATH` to access Ninja.
`apk` installed Installed packages are additionally sorted.
Signed-off-by: Matt Jolly <kangie@gentoo.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33725>
This `mv` copies the folder from the read-only docker image to the
run time overlayfs, which is expensive and unnecessary, and slow on
devices using network disks.
`rm` by comparison is instant, and there is no reason to keep the folder
around if we're taking it away from the expected path anyway.
Fixes: 8d08cde667 ("ci/piglit: Use structured tagging for Piglit")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35500>
Remove use of `eval` when writing `dut-job-env-vars.sh`, as it's
unnecessary. The script only needs to declare variables, not evaluate
them.
Using `eval` introduces parsing issues when variables contain both
single and double quotes, such as in commit titles. Example:
https://gitlab.freedesktop.org/mesa/mesa/-/jobs/77995175#L3188
This job failed to parse `CI_COMMIT_TITLE` and `CI_MERGE_REQUEST_TITLE`
correctly due to mixed quoting in:
Revert "ci: disable Collabora's farm due to maintenance"
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35421>
For pre-merge pipelines, we know that we don't need to run the
container-check jobs unless image-tags.yml has been modified. In this
case, we can just skip the container jobs, because we 'know' that the
containers are present in the upstream repo.
For downstream or off-main pipelines, we still need to run the check
job, because the changed-file tracking is not reliable on other
branches, and because we may need to copy the container image from the
upstream container storage into the user's namespace.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35203>
The rules we want here are pretty simple:
- only run rustfmt when Rust code changes, to the extent that we can
tell what has or hasn't changed (only really reliable for pre-merge)
- make rustfmt success mandatory for pre-merge, advisory for other
branches
Encode that, and make sure we don't run rustfmt when we don't need to.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35203>
Remove the /vkd3d-proton directories from the core LAVA rootfs archive
and upload vkd3d-proton as a separate archive for use as an optional LAVA
overlay.
This reduces the size of the core lava-rootfs tarball and ensures
vkd3d-proton is only deployed when the job needs it.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35167>
Time drift can occur during LAVA job execution due to transitions
between three different clocks.
The process begins in the GitLab job [1], using the CI_JOB_STARTED_AT
variable. If SSH is enabled, we then connect to the DUT through an
Alpine-based SSH client container inside the LAVA dispatcher [2], where
some GitLab-related steps are timestamped by lava_job_submitter.
Finally, the DUT [3] runs and uses the setup-test-env.sh helper to
handle GitLab sections, potentially using a third distinct clock.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35222>
The soft limits cannot go above the hard limits values, so the hard
limits should be configured too, just in case default limits values set
by the kernel or the init process are too small.
E.g. when booting with `init=/bin/sh` we have:
$ cat /proc/1/limits
Limit Soft Limit Hard Limit Units
...
Max open files 1024 4096 files
...
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35126>
We only have 8GB on the Brya Chromebook used for venus testing, and the
job is unstable because using all the available RAM causes OOM kills.
So reduce launch_cvd memory limit to 4GB by default, still allowing to
change the default by setting the CUTTLEFISH_MEMORY variable in jobs
that might want a different value.
This change has been inspired by CROSVM_MEMORY, but a new variable is
used because technically cuttlefish can also use qemu in some setups,
not only crosvm.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35126>
Pass XDG_CACHE_HOME=/data/local/tmp to binaries that load mesa
libraries to avoid the following message on the stderr:
Failed to create //.cache for shader cache (Read-only file system)---disabling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35335>
It is possible that `eglinfo` and `vulkaninfo` provide info on multiple
devices.
Consider only the first device, which is going to be the default one
used by other components, when checking the versions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35335>
New mechanisms to retrieve the GLES and Vulkan driver versions have been
introduced in
- 3029fdde65 (ci/android: Switch to using eglinfo to check GLES implementation, 2025-05-28)
- 3ba9038648 (ci/android: Check Vulkan driver using vulkaninfo, 2025-05-28)
These mechanisms are more robust than the previous one but they do
change the behavior in that the version is not retrieved by an already
running process (e.g. SurfaceFlinger), but by creating new processes
that load the libraries available on the filesystem.
Because of this change of behavior the original version should be
printed **before** pushing the new libraries to the Android guest, so
that developers are able to compare the old and new versions in the logs.
Moreover, the runtime checks do not answer the original question anymore:
"what GLES/VK libraries is surfaceflinger currently using?"
but rather new question:
"what GLES/VK libraries are services going to use when they load?"
So the shell start/stop can very well performed after the version check,
accompanied by a new check on the PID of SurfaceFlinger to be sure that
it has reloaded consequently picking up the new libraries.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35335>