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
As they use `g_test_dbus_*()`, they depend on dbus-daemon, so move them
to the part of the Meson file which lists those tests.
This disables them running on platforms which don’t have `dbus-daemon`
available. Arguably, this should be done by returning an error from
`g_test_dbus_up()` and then calling `g_test_skip()`, so the test is
correctly recorded as having been skipped. But that’s a fix for another
time.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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>
The source needs to be removed from the `GMainContext` before being
unreffed, otherwise the main context and main loop will be kept around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`g_environ_setenv()` and `g_environ_unsetenv()` were correctly returning
`NULL` when their preconditions failed (as the test is supposed to be
exercising). That overwrote the value of `env` without freeing it,
resulting in a leak.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Having compared the debug output, it doesn’t show anything unusual
happening that can’t already be seen from other output, for this test.
This is a partial revert of 8fd71dccc5. The debugging output it added to
other tests may still be useful.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1929
The retry loop for acquiring the lock for the authentication cookie file
currently tries to acquire the lock for 0.5s, then gives up, assumes the
lock file is stale, and deletes it.
That’s great if the lock file *is* stale because it’s been left there by
a crashed process.
It’s not so great if the lock file just happens to have been there every
time this process checked, because the cookie file is highly contested
while (for example) running lots of parallel unit tests.
Check for that situation by comparing the mtime of the lock file and
continuing to retry if it’s changed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1929
