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>
These can be really long; it's helpful to have the sections to be able
to separate the individual builds, as well as to get an idea of where
our time goes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31781>
When we use build-skqp as a sourced script, $0 refers to the overall
build script, which may not be in .gitlab-ci/container/.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31781>
When we use build-angle as a sourced script, $0 refers to the overall
build script, which may not be in .gitlab-ci/container/.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31781>
Most of our build scripts are sourced rather than executed in a
subshell, so they inherit our environment. Allow our firmware script to
do the same by not exiting when we have no firmware to download, as is
the case on arm32.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31781>
All the post-merge pipelines are failing to be created with this error:
'shader-db' job needs 'debian-build-testing' job, but 'debian-build-testing' is not in any previous stage
Like all the other test jobs, shader-db should never run in post-merge
pipelines.
Fixes: 0724b00dad ("ci: run shader-db only when one of the drivers it tests is modified")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31758>
If you're emitting a section header under set -x, you will see:
+ section_start foo "foo"
+ x_off
[the section header]
This is kind of annoying. Instead of trying to squash it everywhere by
dancing around local set +x management, play some extremely stupid
tricks with shells to make sure we never emit it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31602>
