I don't understand why, but somehow the changes in e38631ad...3d9ac270
is causing this 1) in a file that has not changed, and 2) on lines that
are indented identically, with the `for` in the macro being terminated
with a `;` semicolon by the caller, so it looks all good to me.
Silencing this allows me to get the release through, but I probably
won't look back either, so hopefully there won't be a legitimate
instance of that warning in the future 😇
The `meson configure` command is used in `.gitlab-ci/meson/build.sh` to
show a summary of the build configuration, however when the script is
re-used locally on systems when there is a pager the commands blocks
for user input, which can be annoying.
Pass the `--no-pager` option to `meson configure`, so that it never
blocks for user input.
This does not change the behavior in the CI, it just makes the script run
uninterrupted also on local invocations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34289>
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>
