We were already avoiding re-processing a same DLL within the same run
(this can happen when 2 dependencies have themselves a common
dependency). But the dll_link.py script was stateless regarding previous
runs so we might be checking again the same DLLs multiple times (even
though we were not copying them again).
Let's make the script stateful with a new parameter to give a file where
all the previously processed DLL names are stored. I am hoping it would
improve the efficiency of the packaging-win32-native which is suddenly
extra slow (it always times out, even after raising the max job time;
now we time out after 2h30! The 64-bit packaging job just takes 1h,
which is too much already, but still much more reasonable).
Since this is probably much less tested than the default vector icon
case, any bug there might go unseen for some time. So let's add a new
pipeline to check this. I make so this pipeline is not actually run on
every commit (i.e. manually only), then I'll just add a scheduled
pipeline to check the non-vector icon case at regular intervals.
This pipeline also test the icon-list.mk files are not outdated.
Fixes#950
`.gitlab/search-common-ancestor.sh`'s original authors are
Philip Withnall and Frederic Martinsons.
(Jehan/reviewer's note: script further improved by Asalle)
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
This workaround was placed to mitigate race condition.
It was useful for the time being, but not anymore.
Better solution will be introduced in following commit.
Reverting changes introduced in 9c6776fb.
Commit-triggered pipelines on `master` branch are apparently canceling
flatpak pipelines even though the flatpak jobs are not even in the
triggered ones.
In any case, these flatpak pipelines are not triggered often (only
through weekly schedule or manually triggered) so there is no need to
have such a flag.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/340147
I completely forgot that since the installer is built on a Windows
runner, I cannot expect a standard Linux shell syntax.
As a consequence, commit de9a171a19 broke the "win-installer-nightly"
job with the following error:
> The token '&&' is not a valid statement separator in this version.
Rather than trying to find the equivalent command to run on powershell
or whatever, let's just compute the checksum at the end of our installer
creation script.
Somehow the test part of the flatpak job stopped working. The last
instance which worked was 3 weeks ago, but after a lot of debugging I
realized that it is not because of any code change on our side. The
exact same commit which worked 3 weeks ago won't anymore!
The standalone bundle is actually built and works fine when tested
independently. What fails is the `meson test` inside the flatpak
environment. Somehow when GIMP is rebuilt inside the test flatpak
environment, it doesn't build the plug-ins yet one of our tests
(save-and-export) requires plug-ins to open some file formats. Note that
I double-checked, the plug-ins were well built and loading any format
works fine in the standalone flatpak, just not in this specific step.
I am completely unsure what broke, yet it is apparently outside GIMP
code. So for now, I just copy-paste the whole flatpak job which we were
including from another repository and remove the `meson test` part.
Since GIMP looks for its icons at runtime and would output warnings if
it doesn't find them, it's better to install first. Not really sure it's
ideal though, but it will do for now. Maybe I should just g_printerr()
instead of g_warning().
… based on set labels.
If the label "5. Windows Installer" is set, the MR pipeline should
trigger the Windows installer pipeline as well.
If the label "5. Flatpak package" is set, it should generate the flatpak
(not publish it obviously, yet it can be downloaded and installed
manually).
This will allow us to easily test MRs and allow people to test our code
before we merge it to the main branches.
Currently we run the job on a weekly schedule. If we keep a retention
period of 2 days, it means that people will not have access to a nightly
Windows installer 5 days out of 7, which is not useful.
Gitlab has a retention policy not to delete artifacts for last jobs, but
it apparently actually bases this check on being the last pipeline, not
being actually the last job of a given name. Since we have pipelines
running all the time, this retention policy just won't apply to our
installer job which will get deleted.
Cf. https://gitlab.com/gitlab-org/gitlab/-/issues/332142
Without this, the flatpak build is just too long and Gitlab CI just
stops logging it. So we end up with a log saying the quite useless (at
the end):
> Job's log exceeded limit of 16777216 bytes.
> Job execution will continue but no more output will be collected.
We don't even reach babl/GEGL/GIMP builds, which are the most important.
With this little trick, I am redirecting output to a log file and simply
including said log into the artifacts, hence allowing to debug the full
build.
Argh! So it turns out that .publish_nightly template uses already an
only: key so we cannot use rules: (on the other hand I guess using only:
ourselves is alright and concatenate ours and the one in the template).
Fixes:
> jobs:flatpak-nightly config key may not be used with `rules`: only
This clashes with the usage of "rules:" and is even more useless as it
is about checking success of earlier stages (yet this job doesn't need
to wait for any other job).
Fixes CI error:
> jobs:flatpak config key may not be used with `rules`: when
To get a nightly flatpak, GNOME project offers a CI template[0] that can
be extended instead of having to define everything from scratch.
At the core is the "flatpak" job that tries to build the flatpak. If the
build finishes succesfully, the result should be available as a CI
artifact as a flatpak bundle. The app id is the same as on Flathub.
Another part is the "flatpak-nightly" job that publishes the flatpak if
the build succeeded. Without this job, the bundle stays only temporarily.
This job can and should only be run on the "master" branch. This jobs is
started only when the "flatpak" job finishes successfully.
Both jobs can be triggered only thorugh schedules[1]. To finish the
flatpak nightlies setup, a schedule needs to be set.
[0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak
[1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
The logs are just too long for gitlab and ends with:
> Job's log exceeded limit of 4194304 bytes.
This doesn't prevent the job from actually finish successfully. Yet the
day when we will have a build issue, we won't have a way to debug if it
happens close to the end of the installer creation. So let's redirect
both stderr and stdout to a log file and include it in the artifacts.
Unlike what I said in my previous commit, it still just takes too long
to build the installer, whether I move some of the substeps around or
whether I increase the max duration. So rather than increasing max
duration a lot more, let's just add an intermediate stage.
The last stage (installer creation) takes just too much time, and it
exceeded the max execution time (80 min) in my last test build. Instead
of increasing this max execution time, let's move the run of
package-gimp-msys2.sh script in the same step as the build one. Maybe
adding an intermediate stage would have been better conceptually, but
every stage also takes some preparation and finalization time (setting
up the runner, loading, cleaning the uploading the cache, etc.) and our
installer pipeline is already long enough.
So let's just go like this for now.
As a side effect, the last job's log limit was exceeded too since I
added the Python option, which should hopefully also be fixed by moving
steps out of the installer job.
Argh! My previous commit logics was right, but should have been applied
to the Windows builds (where the issue happens). That's what happens
when I hack too late at night!
This is not a fix, only a workaround for the CI to at least not fail
randomly, for the time being.
Basically since meson is running parallel jobs, even when the build
fails because git-version.h doesn't exist yet, while a depending file is
being built, it will still be built immediately after, despite the
failure. As a consequence, re-running `ninja` immediately after (i.e.
running `ninja || ninja`) will make the second build work. If it doesn't
then it's another issue which has to be fixed. But at least we work
around this known race condition in the meson build for the time being.
It's very ugly, but better than current situation. :-/
By enabling this option on Linux, not only will the installer language
file be generated, but the `make check` will also now validate that the
lang list is consistent with existing gettext files (see commit
8a42c6ccc2). So it's useful information to know this for instance as
soon as some translators add a new localization.
Also oppositely remove the option on the MSYS2 native Windows 32-bit
build. For Windows, we only need this option once, as we use the
language files generated by the 64-bit build.
The goal is to make it easier to understand which pipeline is run when,
for future maintenance, and also to make it easy to trigger a specific
pipeline through Gitlab pipeline interface.
- Adding a patch sent to me by Sylvie Alexandre meant to help aalib
build on MSYS2 for Windows 32 and 64-bit.
- Additionally, add an additional patch from myself because it was still
not building properly.
- Also update the config.guess|sub files because the original ones (from
2001!) were just too old and not properly recognizing the host mingw
system (especially the 64-bit one apparently) in the MSYS2 CI jobs of
GIMP.
- Finally regenerate the whole aclocal/libtoolize/autoconf/automake
build system because these old files just don't play nice with recent
autotools though the source files still regenerate fine (despite with
some warnings, but nothing blocking).
- Add crt-git dependency because libws2_32 is in there.
We had an autotools build stopping at `make check` and a separate one
for `make distcheck`. This just seems very redundant hence a waste of
resources.
So let's drop the job gimp-autotools-debian then add a `make check` step
to gimp-distcheck-debian.
Also as a side change, I move the cppcheck to being a scheduled job.
It's not such resource intensive job, nor did it take much time, yet
it's not like we use this information constantly. Moreover it never
fails anyway (so it's not like it gives much information on a per-commit
basis, unless we explicitly look into the resulting files) and with the
ability to run custom jobs whenever we want, this is far enough if
sometimes we need to generate the cppcheck analysis more frequently.
The rest of the time, having 2 jobs of this a week (our current
schedule) is far enough.
Run InnoSetup in the Windows CI to build the installer from both the 32
and 64-bit builds.
Current limitations:
- No installer signature yet.
- Dependencies will have to be checked more thoroughly.
- Apart from babl and GEGL, we may want to make custom builds of any
package which has a patch in build/windows/patches/ (Windows-specific
patches) and build/patches/ (all platform patches).
- Plug-in interpreters (Python, Lua…) don't work. This will need to be
looked at in detail.
Globally this first automated installer build works fine though, as I
could install it in a Windows 10 VM and GIMP ran fine! So it's a first
step towards fully automated releases for Windows.
Having them at each commit is counter-productive, first because these
builds take so long and second because there seems to be quite few
Windows runners. So we end up constantly waiting for CI jobs from
previous commits (so we are just constantly waiting).
This is resource over-usage. So instead, I'll just set this in scheduled
jobs. For release preparation though, we'll have to set up a workflow
later to trigger these jobs off-schedule/on-demand (I can see there is a
Gitlab interface to do this), but this can wait for when the installer
is fully generated by the CI anyway.
Note: Vala API doesn't build well on the 32-bit build. Not sure why (the
meson logs for GObject Introspection build are just as empty as ever),
but it won't generate the VAPI. So I disabled the option on 32-bit.
This new job resulted in a package which allows to run GIMP on Windows
(as tested in a VM; at least it starts, I can create a new canvas and
paint). Of course I think this will need to be tweaked a little bit
more, as I'm sure we miss things here and there.
At the very least, even though I add the Python and Luajit binaries,
GIMP on Windows didn't find them. This will need to be investigated.
Also it looks like opening from a remote location may not work. Not sure
if this about a missing GIO module or maybe something which works
differently on Windows (I was not even able to drag'n drop from the
browser!). Anyway this needs to be looked at as well.
Note that gdk-pixbuf-query-loaders is apparently unneeded when GIMP is
built this way (unlike with our crossroad build).
All this to say that this is still an early attempt to full CI build for
Windows.
It doesn't invalidate the crossroad build, because cross-compilation
builds from Linux will always stay very important for Linux developers
to be able to easily fix Windows bugs too; yet the crossroad build has 2
major issues:
1. We haven't figured out yet how to run GObject Introspection tools for
cross-builds, so the crossroad builds are not full-featured (and this
is quite a major feature we are missing!).
2. Also I will want to run the installer in the CI at some point and the
one we use can only run on Windows itself AFAIK. We could try to run
it through Wine, but still anyway the point 1. is already quite a
blocker, let's do the simple thing.
Note that we will likely want to move to meson for this build, because
autotools is very slow on Windows. But as long as the few blocker meson
bugs are not fixed, let's stick to the slow yet good build.
These are interesting and may find very specific bugs from time to time,
but the usefulness is rare enough not to warrant to run at each commits.
This is just a waste of resources.
For scheduling finesse (in case we want to separate these in separate
scheduling), also rely on the existence of variables during scheduling.
Finally make sure that the non-scheduled builds are not run in schedule
pipelines (they are already run far enough).
The build rules were highly inspired by other projects on GNOME's
Gitlab. All of them used to build with ccache. It worked fine for the
main build, but completely broke GObject Introspection build on both
babl and GEGL. And the worse thing is that meson was absolutely not
displaying the error, just saying it failed (even in verbose mode). A
lot of time wasted trying to debug.
Therefore let's get rid of ccache, but only for babl and GEGL. Keep it
for GIMP itself as it works fine there.
Other minor changes:
* Build from the build dir, rather than source. The other way around
works too, but I actually find commands simpler this way.
* Adding artifacts.
Just an initial test to get a hang of the thing, mostly inspired from
GTK gitlab-ci rules adapted to our build.
All in one job (deps, babl, GEGL, GIMP itself) for now, for simplicity
of debugging. We'll see later to break this into CI sub-jobs.
- Only publish the bz2 tarball because that's what we currently provide
on download.gimp.org (let's see in the future for the xz tarball).
- Generate also a sha512 checksum. It's better to do it on the CI rather
than on the download server, otherwise it wouldn't protect against
transfer errors (from gitlab to download server).
- Rename the checksum files to ${filename}.SHA256SUMS (512 respectively)
for easy download without name clash with the global files listing all
the previous releases.
- Disable all meson jobs for tagged releases. They are currently not
reliable and may fail randomly (see issue #6257), even though without
code problems (this is also one of the reasons why autotools is still
our official build system and meson is still deemed experimental).
It's ok for regular builds, but not for tagged builds, which we need
as reliable as possible. The really important job is the distcheck one
for tags.
This reverts commit 32434d9fc3.
Argh sorry. I was planning on making a branch for this (not directly on
master!) and also the patch should obviously have been applied on a GTK
tree, not GIMP's. I'm probably tired! Reverting.
We were not building it by not installing libmng until now. But graphviz
must have pulled libmng. So disable explicitly the option in GIMP
configure step.
Jehan