Rather than having the whole Win32 cross-build into the 'gimp' stage,
break the dependencies and GIMP-only builds in 2 stages.
Since apparently we need to keep the same structure for the native and
cross build (otherwise we don't get parallel builds; in other words, I
didn't find the possibility to set separate pipelines up), I move babl
and GEGL into the same 'dependencies' stage.
Finally I remove the -base rules extended into actual jobs, except for
`.gimp-base` (this is the only which makes sense as it is actually
common to the meson and autotools build).
We don't need to pull 5 commits of history. Only the HEAD of the
selected branch is needed.
Also define it globally rather than re-defining it in every job to the
same value.
First replace the "when: on_failure" rule by a "when: always". We indeed
always want to get log artifact so that we can study a build if
necessary (neither only on failure nor on success; really on all cases,
since even an apparently successful build may have issues we might want
to diagnose).
Also expire all artifacts at 1 week (it seems the default on GNOME's
Gitlab is 4 weeks; we don't need to keep these so long. Even a few days
might be enough actually).
As for the artifacts contents, keep the build dirs rather than the
install dirs. Build dirs allow to check configuration logs and other
kind of logs which are the most useful when diagnosing a failed build.
Now install dirs are also interesting. Maybe we should provide them
again at some point. We'll see. For now I comment them out.
Still keep the install dir for dependencies though, since it seems this
is how data are passed from one job to another.
Note that ideally we would like to provide different artifacts depending
on failure or success but apparently this is currently not possible.
See: https://gitlab.com/gitlab-org/gitlab/issues/18744
Also not sure why for GIMP, the CI was only keeping the build app/tests/
directory. We should really keep the whole dir.
It was not necessary when I was only running the cross-build job. Not
sure why it is needed now. What do the parallel jobs share exactly in
this CI system? Anyway…
It looks like Arch does not have mingw64 cross-compilers in core package
repository. It does have some package in the user repository (AUR), but
I assume that such a repository cannot be deemed as safe.
Anyway I still tried, but apparently these AUR packages have to be built
and when I tried, I got this error:
> ERROR: Running makepkg as root is not allowed as it can cause
> permanent, catastrophic damage to your system.
Anyway it's all a big mess. Then I tried to move the cross-CI to Debian
testing, which is anyway our base compatibility system. Unfortunately I
encountered like what looked like some glibc++ macro problem on some
packages (most likely because the pre-built packages I use are Fedora
ones which likely uses a cross-compiler differently built from the
Debian one).
So in the end, for simplicity, I use a Fedora image, then I am sure to
get a good match between the system cross-compiler and the pre-built
dependencies.
This is the base system for our CI, and the former mypaint-brushes
package got bumped to v2, which broke the build. Instead of rolling
back, they added a mypaint-brushes1 package. Let's rely on it instead of
installing it ourselves now.
If I get it correctly, archlinux bumped the mypaint-brushes package to
v2, which broke our CI. The v1 and v2 brushes are not the same, and they
are not even compatible (GIMP only supports v1 brushes so far). These
should be different packages, hence the incremented major versionning.
For the archlinux change, see also:
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/mypaint-brushes&id=dfd032b3aab40a46c751bd47713fb82bf11bd984
Let's just install the brushes ourselves from the correct branch.
With this kind of changes, as well as the weird patches they do when
they rename the pkg-config file of libmypaint, I think we should
consider not rely on this distribution for our CI.
We don't actually need any of the Python dependencies at runtime. We
only check for these to make packagers aware of the runtime need. Force
the build to go forward even with these deps.
Jehan