Instead of unpacking the x86_64_build container and its billion build
dependencies every time, switch to using only what's in the minimal
pyutils container, and the Python scripts we get as an artifact from the
python-test job. Pulling the artifacts from S3 rather than using GitLab
is also much more efficient.
This should substantially reduce the runtime required to get to testing.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31151>
Currently, our jobs which only want to run a little bit of python -
python-test and the LAVA jobs - pull the entire x86_64-build image,
which is both massive, and massively unnecessary.
Create a separate image which only carries what we need to run our
Python tests and utilities, and switch python-test to using that.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31151>
It looks like the compute reconvergence tests are slamming us into OOM
on stoney at least; backport a commit which makes this less horrible.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30978>
SC2319 is actually helpful! It's telling us that in:
foo="$(bar)"
[ -n "$foo" ] && ret=$?
ret actually gets us the return code from [ which is by definition zero,
instead of the return code from bar that we wanted.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30978>
This was the only thing running shellcheck and pytest. Unsurprisingly,
tons of them regressed whilst it was gone. Since these have now been
moved to other jobs, we can just bring back debian-build-testing in the
non-critical-path stage if we drop LTO, so let's do that as there hasn't
been any movement towards fixing it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30978>
Without EXTRA_CARGO_ARGS='--target armv7-unknown-linux-gnueabihf',
deqp-runner binary was built for aarch64 architecture for arm32
builds and causing below failures on arm32 target,
/usr/bin/deqp-runner: cannot execute binary file: Exec format error
So pass EXTRA_CARGO_ARGS to cargo to fix this.
Fixes: 83d9cfa5 ("ci/deqp-runner: build from git checkout even on linux")
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31071>
this existed for historical reasons, but realistically now it should
be possible to build mesa with dri3 always enabled. additionally,
this check was often used as a substitute for having drm functionality,
which is sort of similar but also not really a direct match
this simplifies a bunch of conditionals and prevents users from footgunnning
themselves into orbit
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30952>
Placing mtl-fw.json in src/intel/ci/mtl-fw.json works for the
mesa build, but it fails to fetch in drm-ci. Move it to the
.gitlab-ci directory so it is included in the artifacts used
for building the kernel/rootfs in drm-ci.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30947>
Sometimes not all of the jobs execute. For instance, Windows build jobs
will not trigger on AMD-only MRs. Use the 'optional' keyword to ignore
jobs which don't exist in our pipeline.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 310e3bb026 ("ci: do not start build-only jobs until the critical build-for-tests jobs are done")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30926>
MSVC finally gained support for __typeof__ and we want to start requiring
it. Let's bump the version of the build tools we use to v143.
Acked-by: David Heidelberg <david@ixit.cz>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30877>
Once again, making sure the input (*-vkd3d-*.txt) have the same format
as deqp-runner so that users don't have to care which one they're using,
and the output is also in the same format so that tools automatically
handle everything.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24739>
Currently only package versions of firmware files are available in the
rootfs.
This commit allows firmware files to be pulled directly from a specific
git hash of a remote repository.
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30770>
I think these were written with the idea of making it "(build rules) &&
(any relevant driver), but instead the driver rules are bypassing the
build rules because
1) it's not an AND, it's an OR; any line that matches applies, and
2) the driver rules are `when: on_success` when these need to be `when:
manual` like the rest of the build jobs.
Let's stop trying to be special and simply behave like all the other
build jobs.
We can always try making complex rules later, but once we're on a base
that works.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30871>
In forks, every job exists, but no job is automatically run.
Should help with the problem of users clicking on that tempting "play"
button GitLab offers and that has been causing a lot of issues with
wasted resources.
Downside is, users now have to use the `bin/ci/ci_run_n_monitor.sh`
script to be able to run a bunch of jobs at once.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25252>
