Since $RESULTS_DIR is now centrally defined in setup-test-env.sh it's no
longer necessary to manually add a hard-coded results directory for the
b2b-test job results.
This keeps the results directory consistent between b2c-test jobs and lava.
Fixes: 9b6d14aed1 ("ci: Always create results dir from init")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32051>
The RESULTS_DIR variable is defined by reference to the present
working directory, but if the pwd is the root directory then the
$RESULTS_DIR begins with two slashes instead of one like this: //results.
This is harmless but not necessary, so remove it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32051>
People had enough time to migrate to rusticl, also nobody would support
this anyway anymore.
Acked-by: David Heidelberg <david@ixit.cz>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27783>
Update the wrap and the dependency, as well as bumping several build tags.
I've also turned off wayland-protocols tests, as we don't want to bump the
wayland-scanner version at this time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26150>
debian/x86_64_build-base was missing the package that provides
LLVMConfig.cmake, breaking cmake builds that need LLVM, like the
SPIRV-LLVM-Translator build.
The cross-builds were missing arch-test to allow dpkg to figure out
which arch it's running on.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31940>
The `.baremetal-arm64-asan-test` job extends `.baremetal-test` and
`.use-debian/baremetal_arm64_test` but doing this is unnecessary because
all of the arm64-asan jobs also inherit the `.baremetal-test-arm64` job
which does the same thing.
Furthermore when `.baremetal-arm64-asan-test` appears last in the list of
extended jobs, as in the case of the `a630-gles-asan`, the general rules
inherited by `.baremetal-arm64-asan-test` override the more specific
driver rules and prevent the driver job from appearing in the merge
pipeline.
Simply bumping the `.baremetal-arm64-asan-test` job back earlier in the
list of extended jobs would allow the driver rules to take precedence but
then the S3_ARTIFACT_NAME, provided by `.baremetal-arm64-asan-test`, which
is specific for asan builds, is overridden.
By removing the inherited jobs from the `.baremetal-arm64-asan-test`,
this job can continue to provide the asan artifact without interfering
with the driver jobs appearing in the merge pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31916>
The `.baremetal-arm32-asan-test` job extends `.baremetal-test` and
`.use-debian/baremetal_arm32_test` but doing this is unnecessary because
the only job that extends `.baremetal-arm32-asan-test`, i.e.
`gc2000-gles2-asan`, also indirectly inherits `.baremetal-test-arm32`
which does the same thing.
Duplicating the extended jobs in `.baremetal-arm32-asan-test` can
unnecessarily cause rule overrides and unexpectedly remove jobs from
pipelines.
Remove the inherited jobs from the `.baremetal-arm32-asan-test` job so
that (when the necessary farm is enabled) `gc2000-gles2-asan` will appear
in pipelines as expected.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31916>
Now that the LAVAJobSubmitter's `__post_init__` method is working for
unit tests, one of the job definitions parametrized tests started to
fail due to lack of LAVA proxy mocking.
This commit adds the missing pieces.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31882>
python-fire auto-converts `item1,item2` into a tuple, but if there is a
dash `-` inside the argument, it treats it as a string.
Let's validate the data, when it comes as a `str` or `tuple`.
For more details, here are the tested scenarios:
| --lava-tags= | Type | Value |
|--------------|-------|---------------------|
| None | bool | True |
| '' | str | '' |
| tag1 | str | "tag1" |
| tag1, | tuple | ("tag1",) |
| tag-1,tag-2 | str | 'tag-1,tag-2' |
| tag1,tag2 | tuple | ("tag1", "tag2") |
| ',' | str | ',' |
| ',,' | str | ',,' |
| 'tag1,,' | str | 'tag1,,' |
See also:
https://google.github.io/python-fire/guide/#argument-parsing
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31882>
We don't need the /done anymore, because we have better job
dependencies. But the mainline-or-fork query is still helpful, so
refactor that out into a common helper we can reuse for other things.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31882>
Instead of providing a hardcoded set of arguments, allow overlays to be
added to the submitter script. Passing Python dicts as a string
representation and relying on coercion from strings is far from great,
but fire doesn't give anything else, so.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31882>
We compose the rootfs from a mixture of the base rootfs (exported from
the container build stage, currently lava_build.sh, which can be reused
as long as the container isn't rebuilt), the Mesa build overlay
(exported from the debian-* build job, which can be reused for every job
in that pipeline), and the per-job rootfs (containing job-specific
variables which cannot be reused).
Instead of having LAVA pull the base rootfs and separately downloading
the build/per-job parts on the DUT, get LAVA to compose the whole thing
by using overlays.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31882>
Out of 5 run during busy hours, all the jobs that once took 5+ min are:
build-for-tests / debian-arm64-asan 6 min
build-only / debian-s390x 6 min
build-only / debian-android 7 min
build-only / debian-clang 8 min
build-for-tests / debian-arm32-asan 8 min
build-only / debian-vulkan 11 min
build-for-tests / debian-testing 12 min
build-only / debian-testing-msan 12 min
build-only / debian-clang-release 13 min
build-only / alpine-build-testing 14 min
build-for-tests / debian-testing-asan 21 min
The jobs at 10+ min are considered to take long enough that they might
risk crossing the 15 min mark, so let's keep these ones at 30 min and
lower the timeout for everyone else to 15 min.
It's worth pointing out that debian-testing-asan is a build-for-tests
job and as such it blocks build-only jobs from running until it's
finished, which can be a problem for a job that has been seen taking 20+
minutes. We should do something about that, but that's not the topic of
this MR.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31846>
GitLab doesn't (yet) support `timeout:` being a variable, so let's put
the real `timeout:` at the max timeout we want, and internally use
another timeout (using coreutils' `timeout`) that we _can_ set using
a variable.
With that, we can set a 1h timeout on nightly LTO builds while keeping
our tighter 30min timeout the rest of the time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31846>
FORCE_KERNEL_TAG allows testing kernel uprevs without rebuilding
containers by supplying an external kernel directly for booting on
hardware devices. Renaming it to EXTERNAL_KERNEL_TAG clarifies its
purpose, distinguishing it from KERNEL_TAG which rebuilds containers.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31795>
Use a default value for CROSVM_GALLIUM_DRIVER. This change
ensures that if the variable is unset, it defaults to an
empty string. This prevents unbound variable errors with
set -u in the case of drm-ci.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31814>
Running LTO on pre-merge can be time-consuming,
especially on (over)loaded CI.
Let's keep it in nightly jobs to ensure coverage without causing
timeouts in pre-merge pipelines.
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31790>
In function 'r600_init_resource_fields',
inlined from 'r600_buffer_create' at ../src/gallium/drivers/r600/r600_buffer_common.c:561:2:
../src/gallium/drivers/r600/r600_buffer_common.c:121:48: error: array subscript 'struct r600_texture[0]' is partly outside array bounds of 'unsigned char[256]' [-Werror=array-bounds=]
121 | if ((res->b.b.target != PIPE_BUFFER && !rtex->surface.is_linear) ||
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/util/os_memory.h:37
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31790>
