Fixes: #13001#13106#13492#13647#14779
AppImage jobs are now built with Trixie to adress #13001 and many others.
To have two Debian versions with less complexity possible, I needed to:
- Revert the prevalence of the AppImage CI (now nonreloc comes first);
- Revert the use of Clang on Debian (also to save 120MB from registry,
since we now have 4 Docker images, each one with its own STEP cache!).
In short, .gitlab-ci.yml will look more like before I changing it a lot.
While 20min is being enough, the jobs are completing
too close of the due time (due to awful runners like
OSU or Win32 stuckness). Let's prevent failures, then.
Closes: #14796
There is no other doable option than Buildah. I also tested the
other Kaniko alternatives pointed by GitLab documentation which
were Docker-in-Docker and Buildkit but none worked unprivileged.
Regression: our logs will be a bit more noisy compared to Kaniko.
See: https://github.com/containers/buildah/issues/6362
Not making use of 'ref:' makes GitLab fetch the latest version of
the *initiative.yml with the latest fixes and such. That would
not be a problem and even desirable maintenance-wise but that
allows GNOME to add anything on our .gitlab-ci.yml at any time.
This is hard to debug and can break our CI. For example,
see: https://gitlab.gnome.org/GNOME/citemplates/-/issues/35.
Some jobs were using the Debian image from Docker Hub registry:
- meson-health
- clang-format
- cppcheck
- sources-debian
- dev-docs
- dist-appimage-weekly
The reason was that we don't need a bigger image suited for builds
($CI_REGISTRY_IMAGE:build-debian-${DEB_VERSION}-${RUNNER}), but
it relied entirely on luck. If we push too much commits in a day, it
could surpass the Docker Hub limit. So, let's use our own image always.
It is a bit too long and not the ideal naming but with the new one we avoid
the -x64 arch suffix which feels redundant due to the [x86_64_v3] added by GL
This documents meson-health and appimage
Also, remove the speed comments because these pipelines will
run automatically regardless of the developer intention.
Otherwise we don't know what happened in GIMP build. It
is too verbose to output on GitLab runner console due to
flatpak-builder awful messages about .debug stripping.
For the same reason of 3e958583 this will not work.
And even if we manage to have it configured for
containers in the future, it would be slow like b51f2b52.
From the horse's mouth:
"WARNING: appstream-glib is heavy maintenance mode, use appstream
instead"
Additionally, appstream-glib no longer conforms fully to the
appstream specification.
Some care is taken to taken to support both libappstream 1.0 as well
as libappstream 0.16.x to support stable distros.
