It doesn't understand the powershell syntax which leads to the cache
key being empty which leads to cache restore being skipped
which leads to slow builds not using ccache.
See https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2747
They use powershell instead of cmd.exe, use the tag win32-ps instead of win32,
and run Windows 2016 instead of 2012r2.
The old runners will be switched off in the comming weeks.
We need to investigate release-specific failures, and possibly fix our
test suite to deal with debug-specific poking through the internal
state.
For the time being, allow the release job to fail, but this is strictly
a temporary measure.
We are going to need to hide the report generation into the test runner
script, as we want the job to produce the reports even in case of
failure, instead of bailing out immediately.
Now that we figured out why the build was failing on Fedora when the
profiling code was enabled, we can go back to building both shared and
static libraries by default.
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.
