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 😇
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>
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>
What we need is a way to tell GitLab "queue `build-only` jobs after
`build-for-tests` jobs have started", to make sure that `build-only`
jobs don't start before `build-for-tests` jobs and thus delays test jobs
and the overall pipeline.
The best I had found was "queue `build-only` jobs after *all* the
`build-for-tests` jobs have finished", but this introduces a larger
delay than we want, and causes `build-only` jobs to often be the last
ones to finish in a pipeline, after test jobs that respect the 15min
runtime limit.
Instead, we can tell GitLab "queue `build-only` jobs after the
`build-for-tests` jobs have been queued for X minutes", which is closer
to what we want, and in particular this ensures the correct order of
*starting* jobs as long as the CI is not overwhelmed and doesn't manage
to actually start a queued `build-for-tests` job within 5min, in which
case I'd argue we don't care about job order anymore because we have
bigger problems anyway and likely everything's going to timeout.
This also gets rid of the hard-to-maintain `.build-for-tests-jobs` list
of `needs:`, which also needed to be manually merged in half the jobs.
The trade-off is that we need to make a (shallow) copy of the
`.container+build-rules` list, that replaces all the `when: on_success`
with `when: delayed` + `start_in: 5 minutes`. This means that we'll need
to make sure the two lists of conditions remain identical, but this
seems more manageable; nevertheless, I added a comment to remind us.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33564>
Symlinking $CARGO_HOME to /usr/local/bin made rustup uninstaller delete
the entire folder, causing mysterious build errors, so let's do the
traditional .cargo/env sourcing to make rustup available to the rest of
the build scripts.
Also make sure that required scripts run the shell's rcfile to be able
to setup the PATH correctly.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33519>
debian-testing is the critical path: the shortest possible job to build
exactly what we need to execute on hardware, and nothing else.
debian-build-testing exists to give us better coverage at the expense of
running longer.
Since the only jobs using r300 and Nine, and the only jobs using NVK,
are in post-merge stages which are manually triggered, move these builds
to debian-build-testing. This makes the critical path to those a little
longer, but we do get to make it shorter for everyone else just running
regular Marge jobs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
LLVM 15 is pretty old, and notably not supported by either ANGLE nor
Skia anymore. So let's move up to LLVM 19 using packages provided by
LLVM themselves, apart from PPC and ARMv7 which don't have builds.
The Skia build now requires a bunch of new warning exclusions; hopefully
most of these are no longer needed when we can upgrade Skia shortly.
The ci-deb-repo revision has also been bumped to get us a new version of
xtensor which builds with LLVM 19, and a version of spirv-tools which
also works with LLVM 19.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Closes: mesa/mesa#11538
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
We don't actually need this anymore. We were previously using it to find
ccache, but Meson will do this for us. Now that we pass
-Wl,--fatal-warnings, we don't need to pass -Werror to the link stage
either.
This removes two shell execs, one subshell, and one call to each of grep
and printf, per compile.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Sitting here trying to get something else done tonight, I watched the
ASan and UBSan jobs, both on AArch64 and x86_64, regularly blow through
their timeouts.
They should be fixed to do less, but this makes them at least succeed in
the meantime.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Building and linking drivers, Rust code, and tools, takes an inordinate
amount of time with sanitisers. That could be justified if we used the
results to test, but we don't.
Reduce the coverage to get reasonable runtimes back.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Running the Meson tests doesn't take forever, but it does take a
noticeable amount of time.
For jobs in the critical path - like debian-testing and debian-arm64 -
we need them to complete as soon as possible to produce a build for the
hardware tests to consume. Running the tests here lengthens that time,
and introduces more hazard since the tests have previously been prone to
hitting timeouts, requiring the whole job to be retried before we can
proceed. These jobs also have build-only jobs which are not in the
critical path, and can run the tests just as well.
Running the tests under sanitisers is just too slow to deal with in
pre-merge pipelines.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
In order to build the mesa llvmpipe driver for Android, llvm libraries
for Android are needed; force meson to use a fallback for llvm and
provide prebuilt libraries making them available to meson thanks to
a wrap file.
Enable other software drivers for the x86_64-linux-android build, but
also disable the amd and intel hardware drivers for now which don't
build correctly on Android.
Download the prebuilt LLVM libraries for Android in the container job
rather than in the build job, to avoid downloading some big artifacts
for every mesa version built for Android.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Currently the python-test job runs pytest and then creates python
related artifacts for use by other jobs. But the python-test job isn't
triggered by changes to the python scripts and libraries. Instead, changes
to python scripts and libraries can currently be merged without running
pytest and, if they do generate errors, they will only appear in ci
later when trying to generate the python artifacts.
Add pytest to the existing linting jobs and expand the rules so that it
will be triggered by changes to python scripts and libraries. Remove
pytest from the job that creates artifacts. This will ensure that the
artifacts are still valid while catching script/library errors before they
are merged.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
