Enforce a default job timeout of 1 second, to make jobs which don't
explicitly specify a timeout insta-fail, rather than potentially hanging
around for an hour.
Container builds get the full hour as they can run long and are not run
in pre-merge context, and LAVA jobs also get the full hour as they have
multiple internal timeout mechanisms which aim to fast-fail jobs once
they actually start. However, as they just queue jobs to an external
host (shared with other projects like KernelCI), these timeouts aren't
reflected into the GitLab CI definitions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34280>
Most of our build jobs have had a timeout of 1 hour since 6425b6e3d4,
which pushed the timeout as high as possible to allow for LTO building
taking forever. Since then, we've pulled LTO back to only running on the
fedora-release nightly job.
This tries to bring us back to the ideal from 322a83f321, where the
build jobs all have very low timeouts both for the overall job as well
as the build section we run. So if anything goes wrong - apart from
fedora-release - we'll just assume the runner has some environmental
damage, give up, and try again.
Of the build-for-tests jobs, all but the ASan and UBSan jobs regularly
complete in around 5 minutes, apart from debian-testing which is our
critical-path build job for almost all x86-64 testing. This is obviously
not good, but is tracked in mesa#12544.
The build-only jobs not using sanitizers also typically complete in
3-4 minutes, with the exception of debian-clang-release and
debian-x86_32 which are closer to 10 minutes. That's not ideal, but
they're also not currently on the critical path, so we can live with
that.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34280>
This affects:
- generic jobs (sanity, rustfmt, shader-db, docs, etc.)
- linux image builds
- linux mesa builds
- software renderer tests
- android tests
- virgl & venus tests
Marge pipelines get high priority, nightly pipelines get low priority,
and everything else is in between.
(Hardware test farms have their own mechanisms.)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34264>
Mesa is built twice in the same debian-android job, once for aarch64 and
once for x86_64 to catch as many build regressions as possible.
However the install dir used for the two builds is the same, and this
results in a mix of aarch64 and x86_64 artifacts ending up in
install.tar, because .gitlab-ci/prepare-artifacts.sh is called at the
end of the second build.
Having two separate jobs for aarch64 and x86_64 build would be cleaner
but it would also use more resources.
Since the aarch64 libraries are not used for anything for now, a cheaper
workaround is to build x86_64 first and just call prepare-artifacts.sh
after first build.
This way the aarch64 build will still be done to catch regressions, but
the artifacts won't end up in install.tar which is also more consistent
with the fact that S3_ARTIFACT_NAME only has x86_64 in the name
(mesa-x86_64-android-${BUILDTYPE}).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34234>
Previously we'd burn 4 minutes waiting for curl to bang its head
trying to get results which would never emerge. Change this so we don't
fail on a 404, and also pull the retry down quicker, so we'll spend a
maximum of 2 minutes waiting for a server to come back, and no minutes
when the results aren't there to be fetched.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244>
I've also included the CI infrastructure used by each farm, in case an
issue is affecting all farms of a kind, like I don't know, a bug in the
http proxy used by lava & baremetal farms :]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34195>
Different versions of Android might have different ways of getting the
GLES runtime version, so factor this out to a function, so that the
mechanism can be changed in a centralized way.
Also rename MESA_RUNTIME_VERSION to GLES_RUNTIME_VERSION because this is
really what is being retrieved, in the future we might have a similar
check for the vulkan Mesa driver.
While at it remove mentions of SurfaceFlinger in some comments since the
mechanism to retrieve the versions is irrelevant for the purposes of the
checks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
The intel vulkan driver is always built by the `debian-android` job,
since it may be needed for some future job, push it unconditionally, it
does not hurt to have it in the Android system.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
Since ANGLE is always built for Android, always push it even if it is
not going to be tested directly.
Besides simplifying the script, this is also because ANGLE is going to
be mandatory anyway starting from Android 15+ and not having it in the
Android system might cause unexpected failures.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
Remove old mesa and ANGLE libraries before pushing new ones, and do this
using a trailing wildcard, because some versions of Android might have
versioned libraries like /vendor/lib64/egl/libEGL_mesa.so.1 which should
also be removed to avoid any confusion when loading the freshly pushed
ones.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
Some of the commands in cuttlefish-runner.sh, like updating mesa and
ANGLE, are not specific to cuttlefish, in general they can be executed
on any Android device under test.
So split those commands out of cuttlefish-runner.sh and put them into an
android-runner.sh script.
For example, when testing a physical Android device instead of a virtual
device, a mesa-ci job will call android-runner.sh directly instead of
cuttlefish-runner.sh
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34111>
Previously, when rebuilding LLVM for Android, the script would delete the
freshly built LLVM install. This caused the android_build container to
lack LLVM unless the container was rebuilt again, this time without
rebuilding LLVM, and instead just downloading the tarball.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34180>
Ninja was already included in the android_build container, so there's no
need to put it in the Ephemeral packages, which only meant that it was
removed at the end of the LLVM build.
Also, add the usual image tag header at the top of
build-android-x86_64-llvm.sh.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34180>
That tag was supposed to allow these jobs to run faster, but these
runners are currently having disk issues, and the normal runners look
like they're plenty fast enough (at least right now since almost nobody
runs ci jobs ^^).
We might revert this later, but for now let's merge this to unblock CI.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120>
The current `s3cp` implementation does not work anymore after the
migration, and instead of fixing it and propagating the fix down to us,
it's simpler to directly use `curl`.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120>
