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.
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>
