GNOME Bugzilla – Bug 793635
Enable CI for GLib
Last modified: 2018-02-20 13:51:11 UTC
We should use the GitLab CI pipeline to build and test GLib every time objects are pushed to the Git repo.
Created attachment 368618 [details] [review] Allow running gdbus-peer inside a container The /etc/machine-id inside a Docker container is allowed to be empty, so we need to check for that case.
Created attachment 368619 [details] [review] Do not use g_test_incomplete() for missing locales The "incomplete" test state matches the "expected to fail" state (or "TODO", in TAP), but missing locales should just cause tests to be skipped.
Created attachment 368620 [details] [review] Increase the timeout for some GLib tests The CI infrastructure is shared and running inside a containerised environment, which means tests may take more time to finish on it than they would on a faster, personal machine.
Created attachment 368621 [details] [review] ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better.
CI run with the attached commits: https://gitlab.gnome.org/GNOME/glib/-/jobs/8411 The timeouts in attachment 368620 [details] [review] are set at the arbitrary value of 90 seconds after playing with smaller values; 60 seconds may be enough, but we probably want some more leeway.
Comment on attachment 368618 [details] [review] Allow running gdbus-peer inside a container Splinter is failing for me. The three fixes are good; I have some comments on the CI patch itself though.
Comment on attachment 368621 [details] [review] ci: Add GitLab CI description file What about -Dman=true -Ddtrace=true -Dsystemtap=true? It would be good to exercise those options (they default to false).
(In reply to Philip Withnall from comment #7) > Comment on attachment 368621 [details] [review] [review] > ci: Add GitLab CI description file > > What about -Dman=true -Ddtrace=true -Dsystemtap=true? It would be good to > exercise those options (they default to false). That's a good point; I need to check the dependencies needed for dtrace and systemtap.
Enabled systemtap and dtrace on normal builds; enabled man pages in dist builds: https://gitlab.gnome.org/GNOME/glib/pipelines/3752 I've also updated the normal builds to use `--werror` and to use a debug build type, instead of relying on the default; the dist builds use the release build type.
Created attachment 368636 [details] [review] ci: Add GitLab CI description file We're mostly interested into building and testing everything that gets pushed to the repository — including merge requests. When pushing tags, though, we should assume we're spinning a release, so let's run the dist target, and store the tarball, and the generated documentation while we're at it, as artifacts on GitLab. The Dockerfile for the image used for the build is included in tree, and published on Docker Hub. Using a custom image allows us to avoid the costly "download and install build dependencies" phase, as well as controlling the environment a little bit better.
Comment on attachment 368636 [details] [review] ci: Add GitLab CI description file Yes!
Attachment 368618 [details] pushed as d8a3492 - Allow running gdbus-peer inside a container Attachment 368619 [details] pushed as 5459b34 - Do not use g_test_incomplete() for missing locales Attachment 368620 [details] pushed as 8bfedb5 - Increase the timeout for some GLib tests Attachment 368636 [details] pushed as e04d2e8 - ci: Add GitLab CI description file