We should have a single job for building both static and shared
versions of GTK. On the other hand, having a separate job for the
release build would be a plus.
Additionally, we shouldn't use an opaque script to build GTK; the only
step in the process that requires hand-holding is running the tests
suites under Xvfb, and having the build options visible from the YAML
file gives us a better idea of what kind of build we're running.
The msys2 runner has started failing for internal reasons:
- gtk-3-24 times out
- master fails with a ld.exe assertion:
BFD (GNU Binutils) 2.33.1 assertion fail
../../binutils-2.33.1/bfd/cofflink.c:2348
Both seem related to some MSYS2 issue. Until the runner is updated, we
should not block on it.
The JUnit cover report is useful, but only up to a point; for instance,
it's not used unless it's part of a merge request. This means you don't
get a report if you're pushing to a branch that does not have an MR open.
With a simple Python script and some minimal templating, we can generate
an HTML report from the "I Can't Believe it's not JSON™" log that Meson
produces, and keep it as a CI artifact.
GitLab's CI will bail out at the first failure, which means the
JSON-to-JUnit conversion script won't run unless it's part of the same
script that we run for building an testing.
There where some problems (??) with ccache not detecting changes during meson
checks. Setting CCACHE_DISABLE during the meson execution makes ccache not use
the cache and pass things directly to the compiler.
When building GTK through the CI infrastructure, it would help to have
some ways of testing it; for instance, if we want to verify that theme
changes are useful, or if we want to run the result without necessarily
build it locally.
This is where flatpak comes in handy. By having the CI build a flatpak
buundle, and storing it as an artifact, of the GTK demos, we can easily
point developers and designers to an installable binary that won't break
their system, nor will require development tools and environments to
run.
The GitLab cache is kept across jobs, whether they succeeded or not:
this means that if a compiler check fails during the Meson
configuration, the small compiler program gets cached and restored the
next time the job is run, thus failing again.
I've rebuilt the new Docker image we use for CI to include GStreamer in
the dependencies.
We really need to have the Docker registry hosted on gnome.org, to avoid
pointing people at Dockerhub.
The CI runner is pretty slow to set up (takes about 6 minutes to get
through the system dependencies needed to build GTK), and does not work
with dependencies as subprojects.
Until we figure out how to make it work, and make it work a bit faster,
we should drop CI and rely on Continuous for a while longer.
We can revert this commit as soon as we find out how to make things
work.
