This is used by our release scripts on gimp-web.
Let's not generate for other pipelines, however, since they
don't have long life on GitLab and there is no permalinks yet.
Per the (quite off-topic) discussion in #12772, the fact it's quite
broken on Windows, apparently not too maintained anymore and its syntax
clashes with gi-docgen syntax…
Following 4cbb9360
Most of the distros provides the dictionary pre-installed but
some like Gentoo not. So, let's bundle "share/libthai" for
maximum portability.
It was changed to "GIMP-continuous-ARCH.AppImage" because
I had hope of linking GitLab artifacts on gimp-web (which failed)
so let's use "GIMP-GIMP_VERSION-ARCH.AppImage" again.
Also, uppercase AppId 'Continuous' suffix to be consistent with Flatpak.
Partially reverts e01973b9
This makes the AppImage .sh script multiarch aware and
make Debian pipeline a GL 'matrix' for easier maintenance.
As consequence, making an arm64 .appimage is pretty easy now,
so let's make one since this arch is not that rare in Linux.
This provides us fine-grained info on how much time each step take,
making easier to spot stuckness and to quickly understand the logs.
'gimp' jobs normally do not take advantage on this due to log limits
(they expand and crop the log), so I adapted them to only output errors.
---
Also, to reduce logs, all jobs were reviewed with proper GIT_* variables.
The "AppImage platform" don't have releases, every tool is blending edge.
Obviously, it is too prone to broke, and for the first time it got broken.
So, let's move it to a separate job and with less frequency to not broke CI.
The latest appimagetool inserts a runtime with static libfuse in the .appimage.
It also makes the .appimage run way faster and slightly better compressed.
Thanks for helping me with this, @samueru
This avoids calling host libs, fixing the last pendency on !1440 desc.
In other words, the AppImage now can be run, in thesis, in any distro.
Thanks for helping me with this, @samueru
Every artifact from our CI have a pretty name with some reason for it:
- Installer: it is this way on download.gimp.org since ever(?) and that's fine
- Store: follows Microsoft de facto spec of .msix files naming
- AppImage: follows AppImage draft spec of .appimage files naming
But the .flatpak just looks like AUR pkg. So, let's use reverse DNS
naming which is used at least for .flatpakref files. This makes more sense.
Fixes: #12237
We were building with that option disabled here because it was making our
runners to randomly fail at building it. However, that option disabled also
makes some machines to fail, due to its low-level nature. So, there is no
fix for it(?), let's enable then and hope the runners willn't fail again.
Despite building GIMP with Clang helped a lot to make our deps builds robust,
it is very hard to maintain, not because of LLVM but because of freedesktop.
We needed to ensure that the branch of LLVM matched the one of freedesktop on
which GNOME SDK is based. That stopped to work resulting on bad inconsistency:
1) flathub never had a problem; 2) GNOME runners sometimes worked, others not;
3) locally it stopped to work completely, so the .json right now is unportable.
Some annoying bugs were:
- "error: Requested extension *llvm* not installed"
- "Similar refs found for *llvm*"
So, let's end this not using any extension anymore while keeping only the nice
improvements in the custom builds.
Bruno