Alpine 3.19 ships with Meson 1.3.0, which has broken handling of File
objects and their paths. This causes (as far as I can tell)
un-work-around-able breakage of GLib’s build.
See https://github.com/mesonbuild/meson/issues/5273#issuecomment-1851811417
That should be fixed in Meson 1.4.0, but that might not be released for
a while. Because we’re here to test GLib, not Meson, let’s pin the Meson
version in the Alpine CI image to 1.2.3, which we know works and is
reasonably up to date (and is what the other CI images use).
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/3361388
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Because the documentation is no longer built using gtk-doc.
Keep the old option around, but deprecated.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
The `%E` modifier causes dates to be formatted using an alternative era
representation for years. This doesn’t do anything for most dates, but
in locales such as Thai and Japanese it causes years to be printed using
era names.
In Thai, this means the Thai solar calendar
(https://en.wikipedia.org/wiki/Thai_solar_calendar). In Japanese, this
means Japanese era names
(https://en.wikipedia.org/wiki/Japanese_era_name).
The `%E` modifier syntax follows what’s supported in glibc — see
nl_langinfo(3).
Supporting this is quite involved, as it means loading the `ERA`
description from libc and parsing it.
Unit tests are included.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3119
The image uses `alpine:latest`, so let’s drop the ‘stable’ moniker. This
also makes the container registry ID match the Dockerfile name.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
And update all the CI builds to use the latest micro release from that
series, 1.2.3.
This version bump means we can:
- Drop some backwards-compatibility Meson checks
- Fix a periodic CI failure caused by a now-fixed Meson bug
(https://github.com/mesonbuild/meson/pull/10633)
It’s in line with our [Meson version policy](./docs/meson-version.md),
as Meson 1.2.1 is available in
[Debian Trixie](https://packages.debian.org/source/trixie/meson) and the
[freedesktop SDK](c95902f2ed/elements/components/meson.bst).
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
It’s intended to be used with Linux Docker images, and it assumes a
certain filesystem layout of the image being run (in particular, that it
has a `$HOME/subprojects` directory pre-populated with the subprojects
for glib.git). That’s not the case for Hurd, which is running on a
dedicated runner (not using Docker), so drop this include.
This should fix the CI failure here:
https://gitlab.gnome.org/GNOME/glib/-/jobs/3223275
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The files here are copied from the docs-gtk-org
branch of gtk.
This adds gi-docgen to the CI Dockerfiles and ensures the new versions
(including the OS upgrades from the previous commit) are used during CI.
Helps: #3037
Follow-up to e234a4496e to remove the old
`only: main`, which was overriding the changes from that commit.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Since commit b9b7816e5a, the `pages` job
will still try to be run on `main` after an MR is merged, but will fail
because it depends on `coverage` and `style-check-advisory`, which are
no longer run on `main` after a merge.
See https://gitlab.gnome.org/GNOME/glib/-/pipelines/560680 for an
example failure.
Instead, make the `pages` job only run at the end of a scheduled CI run.
Its dependent jobs will have run then. This means that the ‘canonical’
code coverage report at
https://gnome.pages.gitlab.gnome.org/glib/coverage/ will be updated once
a week, rather than after every merge into `main`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
This works around GitLab issue
https://gitlab.com/gitlab-org/gitlab/-/issues/391756, which manifests as
the error message:
```
Updating/initializing submodules...
Submodule 'subprojects/gvdb' (https://gitlab-ci-token:[MASKED]@gitlab.gnome.org/GNOME/gvdb.git) registered for path 'subprojects/gvdb'
Synchronizing submodule url for 'subprojects/gvdb'
fatal: not a git repository: subprojects/gvdb/../../.git/modules/subprojects/gvdb
```
on between 1/10 to 1/2 CI runs.
See the GitLab issue for a writeup.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s almost a complete waste of time at the moment. For several reasons,
jobs flakily fail on it more often than they succeed. It’s wasting
resources, slowing down development and making people quite frustrated.
* https://gitlab.gnome.org/Infrastructure/GitLab/-/issues/627
* https://gitlab.gnome.org/GNOME/glib/-/issues/2949
* https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3462 and related
test failures
Nobody has stepped up to deal with the test or CI runner flakiness, or
generally maintain this CI runner. If someone does care about preventing
regressions for GLib on macOS, and can put time into making the CI
reliable, then this commit can be reverted.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
MRs are already tested in CI before merge, so it’s redundant and a waste
of resources to test them again after merge.
In the rare case where something breaks post-merge (perhaps because
several MRs have been tested individually and merged, but interact with
each other badly), that’ll be caught in the weekly scheduled CI run.
YAML inspiration from https://stackoverflow.com/questions/63893431/gitlab-run-a-pipeline-job-when-a-merge-request-is-merged
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s not produced anything but false positives for several years now,
and it would be better to save the CI/analysis/triage resources and
instead focus on `scan_build` reports, which generally seem to be more
useful.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a departure from our policy of using the minimum required Meson
version, but I think it might be worth a try to see if it fixes the
persistent intermittent build failures on these platforms due to what
looks like build dependency graph issues.
For example:
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2579411
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2578792
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2579220
- https://gitlab.gnome.org/pwithnall/glib/-/jobs/2588507
I was looking at trying to diagnose some of these failures in order to
potentially file bugs against Meson, but the first step is really to
test against the latest version of Meson. So here we are.
Crucially, our other CI jobs continue to use the minimum Meson version
required by GLib, so we continue to test that GLib builds with its
minimum dependencies. I do not plan to change that.
Also crucially, this MR continues to use a specific Meson version,
rather than asking `pip` to install the latest available. Doing that
could lead to unexpected regressions in future, and that’s not what
GLib’s CI is meant to be testing for.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This reverts commit 91f14cd058.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
It should be enabled in all builds, not just CI builds. Otherwise
developers might miss it locally.
This updates commit f11b96f255.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This doesn’t enforce licensing/copyright headers to be present on all
files, but does check that at least a minimum number of files are
correct.
This should help avoid new files being added without appropriate
licensing information in future.
The baseline is set at what `reuse lint` outputs for me at the moment.
See https://reuse.software/tutorial/#step-2 for information about how to
add REUSE-compliant licensing/copyright to files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
-Wnonnull is sort of fickle and it's an option a lot of consumers
of glib use.
This commit makes sure it gets used on linux during CI as well, so
we can catch compat problems before they hit our users.
To better reflect its purpose.
This will also help distinguish it from a job being added in a following
commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Setting installed_tests option enforces various test files to be
installed, this causes meson to build tools that might have not built
otherwise but that are still required for testing.
Also, disabling installed tests lead to slightly different code paths
when it comes to using test test files.
So, disable it for debian so that we can ensure that at test time we
have set all the dependencies between test programs and the used
resources (that can be libraries, external programs or modules).
We have tests that are failing in some environments, but it's
difficult to handle them because:
- for some environments we just allow all the tests to fail: DANGEROUS
- when we don't allow failures we have flacky tests: A CI pain
So, to avoid this and ensure that:
- New failing tests are tracked in all platforms
- gitlab integration on tests reports is working
- coverage is reported also for failing tests
Add support for `can_fail` keyword on tests that would mark the test as
part of the `failing` test suite.
Not adding the suite directly when defining the tests as this is
definitely simpler and allows to define conditions more clearly (see next
commits).
Now, add a default test setup that does not run the failing and flaky tests
by default (not to bother distributors with testing well-known issues) and
eventually run all the tests in CI:
- Non-flaky tests cannot fail in all platforms
- Failing and Flaky tests can fail
In both cases we save the test reports so that gitlab integration is
preserved.
