This adds to the CI a cross build for Android NDK r16 API 21 (because
thats what GStreamer currently use) for arm64.
GNU iconv must be built manually into our docker image because Android
NDK doesn't seems to ship it. The latest NDK r17 API 28 has iconv.h but
iconv_open() symbol isn't found by the linker. Looks like broken NDK.
libffi also needs to be built manually because the meson subproject
doesn't support building for Android platform. It needs a recent RC
release because latest stable release is 4 years old and fails to
build.
Fixes#1385.
GitLab can then use this to annotate each pipeline with its code
coverage statistics. It can only use one figure, so we choose lines
(rather than function or branch coverage) since it’s the most intuitive
figure.
This parses the ‘lines’ line from output like:
Overall coverage rate:
lines......: 76.7% (108959 of 142122 lines)
functions..: 80.7% (10294 of 12763 functions)
branches...: 51.3% (50226 of 97953 branches)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It looks like the coverage generation makes the tests a bit slower and
some are now hitting timeouts. Flaky tests are always more annoying than
slow ones, and we don't know how much resources we get under CI,
so increase the timeout.
https://bugzilla.gnome.org/show_bug.cgi?id=795636
Use lcov for both Fedora and MSYS2 to create coverage reports and add a second
ci stage which merges the coverage and creates a html report using genhtml.
In the final stage, which is only run on master, the result is published on
gitlab pages.
https://bugzilla.gnome.org/show_bug.cgi?id=795636
This builds glib using meson/ninja/ccache with mingw-w64 on a Windows
machine.
The CI scripts expect a gitlab runner to exist with the "win32" tag
which uses the default "cmd" shell by default.
Before running the tests pacman is invoked to update the system
(potentially including bash etc, thus the extra step)
Then a login shell is started with CHERE_INVOKING to not change the
cwd and finally the test script is executed.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
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.
https://bugzilla.gnome.org/show_bug.cgi?id=793635
