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.
We were regressing on Python style too often. Since Python code style is
a lot easier to enforce than C code style, split it (and the shellcheck
checks) out from `style-check-diff` into a new CI job which is allowed
to fail the pipeline.
Only trigger it when .sh or .py files have changed, which should reduce
resource consumption.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This disables the following warning, which was causing CI failures on
macOS when building the libpcre2 subproject:
```
../subprojects/pcre2-10.40/src/pcre2_error.c:66:3: error: string literal of length 4380 exceeds maximum length 4095 that ISO C99 compilers are required to support [-Werror,-Woverlength-strings]
```
We don’t want to explicitly rely on using overlength strings in GLib,
which is why this change is a `CFLAGS` in the CI configuration, rather
than setting a project-level argument in `meson.build`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since the macOS CI jobs are run on a machine which isn’t using a
pre-made container image, we can’t ship a cached version of the
subproject, so it has to be pulled as a git submodule.
GitLab doesn’t do that by default unless you set
`GIT_SUBMODULE_STRATEGY` to something other than `none`.
See https://docs.gitlab.com/ee/ci/git_submodules.html
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is in preparation for porting `GRegex` to libpcre2, which is
happening in !2529. It’s a big port, though, and specially rebuilding
the CI images to add libpcre2 for it is a pain.
Add libpcre2, and then !2529 can drop the old libpcre dependencies when
the port lands.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1085
This means we can specify the standard options for testing GLib under
valgrind consistently, so that developers can use `meson test
--setup=valgrind` to run them.
Port the existing valgrind CI to use them (this will not change its
functional behaviour).
Suggested by Marco Trevisan at
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2717#note_1478891.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
iconv is complicated to look up. That complexity now resides in
Meson, since 0.60.0, via a `dependency('iconv')` lookup, so use that
instead.
No effort is made to support the old option for which type of iconv to
use. It was a false choice, because if only one was available, then
that's the only one you can use, and if both are available, the external
iconv shadows the builtin one and renders the builtin one unusable,
so there is still only one you can use.
This meant that when configuring glib with -Diconv=libc on systems that
had an external iconv, the configure check would detect a valid libc
iconv, try to use it, and then fail during the build because iconv.h
belongs to the external iconv and generates machine code using the
external iconv ABI, but fails to link to the iconv `find_library()`.
Meson handles this transparently.
Rather than carrying the copylib around inside GLib, which is a pain to
synchronise and affects our code coverage statistics.
This requires updating the CI images to cache the new subproject,
including updating the `cache-subprojects.sh` script to pull in git
submodules.
It also requires adding `gioenumtypes_dep` to be added to the
dependencies list of `libgio`, since it needs to be build before GVDB as
it’s pulled in by the GIO headers which GVDB includes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2603
They are [currently
failing](https://gitlab.gnome.org/GNOME/glib/-/jobs/2032874) with the
error:
```
1/273 glib:glib / array-test FAIL 0.19s killed by signal 11 SIGSEGV
05:04:16 G_DEBUG=gc-friendly G_TEST_BUILDDIR=/builds/GNOME/glib/_build/glib/tests MALLOC_CHECK_=2 MALLOC_PERTURB_=133 G_TEST_SRCDIR=/builds/GNOME/glib/glib/tests valgrind --tool=memcheck --error-exitcode=1 --track-origins=yes --leak-check=full --leak-resolution=high --num-callers=50 --show-leak-kinds=definite,possible --show-error-list=yes --suppressions=/builds/GNOME/glib/tools/glib.supp /builds/GNOME/glib/_build/glib/tests/array-test
----------------------------------- output -----------------------------------
stderr:
valgrind: m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.
------------------------------------------------------------------------------
```
I’m not really sure what that means, but `show-execution-environment.sh`
says the FD soft limit is set to 524288 on the CI machine. That seems
high; on my machine it’s only 1024 (and the valgrind tests pass). So
let’s try 1024.
The valgrind CI has been failing since we most recently upgraded the CI
image to a new version of Fedora.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The runner machine is offline and there is no ETA on when it will be
back, so disable the CI job which uses it for now so that pipelines
can proceed.
See https://gitlab.gnome.org/Infrastructure/GitLab/-/issues/558
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Meson used to try and guess at the Python path. While this worked fine
for GLib before, it probably didn’t work 100% for other projects, so
Meson have made it an explicit option.
Set that option with the Python path used on the Windows CI machines.
This fixes a Meson warning with Meson >0.60.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Move the lcovrc file to the root of the project, so that it’s picked up
by Meson when running `ninja coverage` locally.
See https://github.com/mesonbuild/meson/issues/4628
This won’t affect the code coverage run on the CI, since that explicitly
used the lcovrc file already.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They are functionally quite similar, and combining them saves around 1
minute of CI runner time per pipeline, which is a nice saving for very
little downside.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The default is 30 days, but we don’t need them around that long. This
should free up some disk space on the GitLab/CI runner systems.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
libgamin was last released in 2007 and is dead
[upstream](https://gitlab.gnome.org/Archive/gamin). Distributions may
still ship it (although Fedora no longer does), but we want people to
use inotify on Linux since it’s actively supported.
BSDs use kqueue. Windows uses win32filemonitor.
FAM might still be used on some commercial Unix distributions, but there
are no contributors from those distributions, and certainly no CI for
them to prevent regressions.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2614
Don’t take the opportunity to add support for Android API 31 or update
the version of the Android NDK we’re using to r23b, though, as I
couldn’t quickly get that to work and ran out of time.
Bumping the Fedora version will at least reduce our CI repository disk
usage through sharing the base image.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2605
This is the oldest still-supported version of Fedora.
It no longer ships gamin.
This should fix the installed-tests, which rely on version 0.19 of
python-dbusmock. Fedora 33 only had 0.18.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Test failures were previously ignored on macOS because there are 12
tests which consistently fail (and have not yet been fixed, because
there are no regularly active macOS maintainers for GLib; you could help
here!).
However, this means that new test failures can’t be spotted.
So, explicitly mark those 12 tests as `should_fail` on macOS, and then
make other test failures cause failure of the CI run.
We can track the process of fixing those 12 tests on #1392 and #1251.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
Rather than running them on each commit on `main`. This saves resources.
Given that Android API 28 and FreeBSD 13 jobs continue to be run on each
commit on `main`, this seems like an acceptable tradeoff. It’s very
unlikely that a regression will happen which affects the older systems
and *not* the newer systems. If it does, it will be caught within a week
by the scheduled job.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This clarifies the intent of the `branches@GNOME/glib` selector. It
introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As with a previous commit, `.only-default` does things which are
orthogonal to what `.build-linux` does, so it’s clearer and more
extensible for CI jobs to specify both in their top-level `extends`
statements, rather than relying on `.build-linux` to pull
`.only-default` in.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the name a bit more descriptive, and makes it match the rest
of the naming scheme.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This name is more specific to what the template actually does.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`.build` and `.only-schedules` are orthogonal, and I want to use
`.only-schedules` together with `.cross-template` in future, which would
require creating more cross-product templates.
Avoid that by splitting `extends: .build-only-schedules` into
```
extends:
- .build
- .only-schedules
```
Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They were needed for `GMemoryMonitor` support. That was first included
in the gobject-introspection 1.63.2 release and the xdg-desktop-portal
1.5.4 release. The Fedora 33 image we’re using for CI has versions
1.66.1 and 1.8.1.
This should speed up the `installed-tests` CI jobs a bit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There are no compiler warnings when building on macOS CI at the moment,
so let’s keep it that way by turning any future ones into errors.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is an attempt to fix a persistent error on the macOS CI:
```
Objective-C compiler for the host machine: cc (clang 10.0.0)
Objective-C linker for the host machine: APPLE ld 409.12
WARNING: No include directory found parsing "cc -xobjc -E -v -" output
meson.build:761:2: ERROR: Fatal warnings enabled, aborting
```
For example, seen on https://gitlab.gnome.org/GNOME/glib/-/jobs/1618966.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is what’s available in the new Debian Stable, so we can expect it
to be available pretty much everywhere.
Subsequent commits will clean up old workarounds.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Work around a bug in Meson versions < 0.50.0 where
`--wrap-mode=nodownload` would disable the use of fallback subprojects,
even if they’d already been downloaded, with the message:
```
Cross dependency libpcre found: NO (tried pkgconfig and cmake)
Cross dependency libpcre found: NO (tried pkgconfig)
Not looking for a fallback subproject for the dependency libpcre because:
Use of fallbackdependencies is disabled.
meson.build:1998:2: ERROR: Dependency "libpcre" not found, tried pkgconfig
```
This workaround can be dropped in the near future when we bump our Meson
dependency to something less ancient. We have a self-imposed requirement
to be buildable using what’s packaged in Debian Stable, which is
currently Meson 0.49.2 — but the new Debian Stable release is coming
soon, with an updated Meson.
Using `--force-fallback-for=libpcre` would have been a more constrained
workaround, but unfortunately that argument didn’t exist in Meson 0.49.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962
This should maintain equivalent functionality, apart from that now you
have to pass `--force-fallback-for libpcre` to `meson configure` in
order to use the subproject; rather than specifying
`-Dinternal_pcre=true` to use the internal copy.
This also fixes#642, as the wrapdb copy of libpcre is version 8.37.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962Fixes: #642
It’s a more inclusive name, has the same tab-completion prefix, and is
the default choice for new repositories created locally by git, and on
GitHub and GitLab.
https://sfconservancy.org/news/2020/jun/23/gitbranchname/
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2348
Rather than specifying the default branch explicitly, allow the origin
to choose it. Specify the `--single-branch` option explicitly to make it
clear the CI only needs one branch; this is however already implied by
the `--depth` option so is not strictly necessary.
This will help avoid breakage if gobject-introspection changes its
default branch name in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2348
Run `systemd-machine-id-setup` when creating the image, so that
`/etc/machine-id` is created with a valid ID. Since systemd isn’t
started when running the CI image with podman/Docker, it’s not created
otherwise. This causes some tests to fail.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
So the tests can access `/var/lib/dbus/machine-id`. This is not a
behaviour change relative to older behaviour on CI.
In future, it might make more sense to revert this commit and change the
CI scripts so they symlink
`/home/user/glib-installed/var/lib/dbus/machine-id` to the system
machine ID; or ensure that `/etc/machine-id` exists on all the CI
machines. That’s too complicated to do right now though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It doesn’t seem to be possible to use `only:changes` from a branch
pipeline extending `.only-default` and have it correctly trigger when
`*.sh` or `*.py` files are modified.
We possibly need to convert all our pipelines to be merge-request-only,
but that’s an avenue I’ve been down before and I couldn’t get it to
work. Using
[`workflow:rules`](https://docs.gitlab.com/ee/ci/yaml/README.html#workflowrules)
might fix that, but I don’t have time to rework the entire CI to use
that now.
So in the meantime, move the SH and Py checks into the existing
style-check job so we’re not always spinning up two additional container
instances on every merge request.
See !1743.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
