It is really useful on pipelines used only for testing:
- GIMP_CI_MESON_CLANG
- GIMP_CI_MESON_MSVC
- GIMP_CI_MESON_APPLECLANG
- GIMP_CI_RASTER_ICONS
- GIMP_CI_CPPCHECK
This fixes issue-bot wrongly in the middle of nightly packages,
which was not my intention, since these pipelines are flaky
and all are run with CI_COMMIT_TAG before the releases (with
exception of the flatpak, which is checked by the packager when
syncing the manifest, so issue-bot is also useless there)
We were using VCPKG_DEFAULT_TRIPLET, which makes impossible to
use x64-windows-release triplet since vcpkg starts to crosscompile
(even on the same arch). Let's fix this by using the right env var.
Hmmm why this was not already enabled? On my tests, it works.
Don't remember why I have not handled this before.
This commit also reorder the xdg-mail position on macOS script.
While we want to try with the last tagged release (babl 0.1.124), we
still need the CI to work with the latest code. So let's add one more
temporary fix.
… rename for babl.
As we are doing test build for the release, we are in this in-between
situation where GEGL has the newly named option, but not babl (because
we don't have a new babl release).
I don't know if we'll have a babl release by the time we'll get GIMP
3.2.2 out, but for now, let's use the old option name.
This commit will have to be reverted later, after we release.
The Hessele runner started to complain about the artifacts size and
the macports/ dir as artifact is not needed on a non-splitted job.
It was a leftover from the inspiration from Flatpak scripts.
(On Flatpak it is needed becase if we don't pass .flatpak-builder as
artifacts the gimp job will not know that babl and gegl were built)
More preparition to x64 support
As a ugly regression, it will not be possible to create .dmgs on
forks anymore without an explicit "Run pipeline" from a Developer.
I hope to fix that when we take our sponsored runner from CircleCI.
Thanks to various improvements on babl and GEGL repos they now build cleanly.
So, let's take advantage of Clang senstive semantic analysis on future builds.
For now, this is limited to such projects and on GNU Clang and Apple Clang,
since there is still a bit of work to do on Clang-CL (MSVC) side.
Too much RUN calls are not efficient. First, VFS uses a lot of IO at each RUN;
second, each RUN is cached as layer (we had more than one hundred layer tags!).
(Not that this does not apply to Dockerfile2 which uses no layers.)
This compresses our images at push with ZSTD and default level 3.
This saves at least 90MB of storage from each Debian image and
190MB from each Ubuntu image. In total, we saved aprox. 690MB.
Following 6245e4ee
In addition to producing testable packages by adding certain labels
(which only developers can do), now we can produce such packages by
adding the same label in the issue description. This facilitates to
non-developers generating such packages (e.g. new GsoC contributors).
While it was good to know the bundling is running fine,
this had the risk of people taking them as official.
So, let's be consistent with GNU Clang and Clang-CL builds.
This makes the macOS builds way faster (aprox. 1hr instead of 3.5hr)
thanks to local caching of GNOME runner. We, however, still need to
split them since the timeout is relatively small on such runner.
Since the COMMIT_SHA, we default to build with MacPorts which is more native.
But it is wise to not be overly reliant on it, since it tends to be very flaky,
and Mac platform have very restrictive hardware with software always changing.
By using a pre-made .DS_Store file, this bypasses Apple Script
restrictions which made impossible to set custom background on CI.
We don't have rights to tweak com.apple.TCC like gimp-macos-build.
.DS_Store is a binary file, but it is tiny and rarely updated,
which follows the precedent of build/windows/store/*.pfx.
