This doesn’t change how they run, but does split the code out a bit and
mean we can interleave it with comments. Should make it a little less
vile.
Suggested by Emmanuele Bassi; see !1252.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This makes things slightly more extensible in future, but introduces no
functional differences right now.
See https://docs.gitlab.com/ce/ci/yaml/README.html#extends.
Suggested by Jordan Petridis.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Since we added `only: [merge_requests]` for the `style-check-diff` job,
that started running detached pipelines only for merge requests and only
containing that job, and not running the other jobs for merge requests
(only for branches).
That wasn’t the intention.
Follow the guide on
https://docs.gitlab.com/ee/ci/merge_request_pipelines/index.html#excluding-certain-jobs
to ensure that all jobs (including `style-check-diff`) are run for merge
requests.
This means we can no longer unconditionally use
`${CI_MERGE_REQUEST_TARGET_BRANCH_{NAME,SHA}}`, since they are only
defined for jobs which are running against a merge request rather than a
branch. Instead, use some `git rev-list` magic from
https://stackoverflow.com/a/4991675/2931197 to find the newest common
ancestor commit between the detached head that CI is running on, and the
known or likely target branch. Do the style check against the diff
between the newest common ancestor commit and the detached head.
(Note that `${CI_MERGE_REQUEST_TARGET_BRANCH_SHA}` was never actually
defined for any of our pipelines, since it’s only available for CI
pipelines running on merged branches, which is a GitLab Premium
feature. Oops, my bad.)
In order to find the newest common ancestor commit, we need to pull the
upstream remote, since the CI pipeline might be running on a fork of the
main repository where various branches (particularly `master`) are out
of date.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We can use a template to factor these out and make things a bit more
maintainable. This should introduce no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This shouldn’t affect them (since it just adds the `clang-format-7`
package), but it’s good to keep everything on the same version.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
See: #1552
Add a separate CI job which runs memcheck on the unit tests. This is
done as a separate job from the main build, since we don’t want it to
interact with code coverage at all.
Currently, failure of this job is ignored. Issue #333 will eventually
fix that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #487
The build artifacts from earlier jobs in the pipeline all use the
`_build` directory. When they are copied in to the scan-build job, they
are probably marked as read-only. This means that the `meson scan-build`
run can’t write to `_build/meson-logs/meson-log.txt` and fails.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Use Meson’s support for running scan-build (Clang’s static analyser)
against the build, so that we get static analysis of each pipeline. Add
it in a new pipeline stage, after code coverage, so that we don’t waste
resources on it unless the unit tests pass — a static analysis build
takes perhaps 10× as long as a normal GCC build.
https://mesonbuild.com/howtox.html#use-clang-static-analyzer
Currently, the static analysis results are uploaded as artifacts, but
the job will always succeed (regardless of whether there are any bugs
found in the analysis).
Currently, a large number of reports are outputted by the analyser,
which need to be fixed before we can gate the pipeline on it.
Furthermore, in order to get scan-build to exit with a non-zero status
if any bugs are found, we need to depend on Meson ≥ 0.49.0, which
contains the fix https://github.com/mesonbuild/meson/issues/4334,
allowing us to add the following to .gitlab-ci.yml:
```
variables:
# Exit with a non-zero status if any bugs are found
SCANBUILD: "scan-build --status-bugs"
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
GitLab can show the results of a CI pipeline if the pipeline generates a
report using the JUnit XML format.
Since Meson provides a machine parseable output for `meson test`, we can
take that and turn it into XML soup.
We want GLib to build correctly with this defined, and for all its tests
to still pass.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1708
This effectively renders those tests useless (since realistically nobody
runs tests locally), but it’s better than every other CI run failing for
unrelated reasons. The idea is that the ‘flaky’ tag can be temporarily
applied to a test while a problem is being investigated or fixed, and
then removed later.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Since we are unable to promote our FreeBSD runner to a shared runner,
we can only enable it in GNOME group. This should avoid problems when
submitting merge requests from forks.
While we can’t add markers to the macro implementations to cause lcov to
ignore them automatically, we can change our lcov configuration to
ignore all calls to them.
See https://github.com/linux-test-project/lcov/issues/44.
This causes all the un-takeable branches and un-reachable assertions to
be ignored by our code coverage, which bumps our statistics:
• Lines: 74.9% → 74.8%
• Functions: 82.3% → 82.3%
• Branches: 53.3% → 64.2%
The rationale is that nobody should be testing programmer error
handling, as g_return_*if_fail() are used to guard against — so it’s not
reasonable to count missed branches like that in code coverage
statistics.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This partially reverts commit bfc362cb68.
The FreeBSD CI runner still seems to be a bit flakey, and appears to be
offline entirely at the moment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
It fails because dist-job (correctly) doesn’t build with the code
coverage CFLAGS enabled.
Leave coverage to be generated on master and development branches.
See this pipeline for an example of when it fails:
https://gitlab.gnome.org/GNOME/glib/pipelines/26349
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Similar issue was fixed with commit f929d148, but it's happening again.
Define G_MESSAGES_DEBUG=all when running CI to ensure we won't regress
anymore.
