After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795636 - gitlab-ci: generate test coverage reports
gitlab-ci: generate test coverage reports
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2018-04-28 19:03 UTC by Christoph Reiter (lazka)
Modified: 2018-05-02 12:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ci: collect test coverage and deploy a html report through gitlab pages (6.17 KB, patch)
2018-04-28 19:03 UTC, Christoph Reiter (lazka)
none Details | Review
ci: collect test coverage and deploy a html report through gitlab pages (6.27 KB, patch)
2018-04-30 11:52 UTC, Christoph Reiter (lazka)
committed Details | Review
ci: use timeout-multiplier=2 for running the tests (1.10 KB, patch)
2018-05-02 12:22 UTC, Christoph Reiter (lazka)
committed Details | Review

Description Christoph Reiter (lazka) 2018-04-28 19:03:14 UTC
Created attachment 371500 [details] [review]
ci: collect test coverage and deploy a html report through gitlab pages

This reports something like https://creiter.pages.gitlab.gnome.org/glib/coverage/index.html

Feedback welcome.

btw, I get regular test timeouts on my glib fork with this and I'm not sure if it is related to coverage data generation. meson test has a "--timeout-multiplier" option which we should use there imo.
Comment 1 Philip Withnall 2018-04-30 09:42:30 UTC
Review of attachment 371500 [details] [review]:

Overall, I think this is a great addition. I’m not a fan of all the little scripts that are starting to accumulate in the .gitlab-ci directory, but I don’t know of an alternative.

Emmanuele, what do you think?

::: .gitlab-ci/run-docker.sh
@@ +8,2 @@
     --file "Dockerfile" .
+sudo docker run --rm --security-opt label=disable \

Why disable security labelling?

::: .gitlab-ci/test-msys2.sh
@@ +36,3 @@
+
+cd ..
+curl -O -J -L "https://github.com/linux-test-project/lcov/releases/download/v1.13/lcov-1.13.tar.gz"

Can we have some kind of a crypto signature or SHA512 sum check on the downloaded tarball please? Otherwise if the LTP gets compromised, so does GLib.
Comment 2 Christoph Reiter (lazka) 2018-04-30 09:55:08 UTC
(In reply to Philip Withnall from comment #1)
> Review of attachment 371500 [details] [review] [review]:
> 
> Overall, I think this is a great addition. I’m not a fan of all the little
> scripts that are starting to accumulate in the .gitlab-ci directory, but I
> don’t know of an alternative.
> 
> Emmanuele, what do you think?
> 
> ::: .gitlab-ci/run-docker.sh
> @@ +8,2 @@
>      --file "Dockerfile" .
> +sudo docker run --rm --security-opt label=disable \
> 
> Why disable security labelling?

oh, right, that's a bit unrelated. this makes the command work on fedora with selinux enabled, otherwise mounting of the glib sources fails there.

> ::: .gitlab-ci/test-msys2.sh
> @@ +36,3 @@
> +
> +cd ..
> +curl -O -J -L
> "https://github.com/linux-test-project/lcov/releases/download/v1.13/lcov-1.
> 13.tar.gz"
> 
> Can we have some kind of a crypto signature or SHA512 sum check on the
> downloaded tarball please? Otherwise if the LTP gets compromised, so does
> GLib.

ok
Comment 3 Philip Withnall 2018-04-30 11:07:56 UTC
(In reply to Christoph Reiter (lazka) from comment #2)
> (In reply to Philip Withnall from comment #1)
> > ::: .gitlab-ci/run-docker.sh
> > @@ +8,2 @@
> >      --file "Dockerfile" .
> > +sudo docker run --rm --security-opt label=disable \
> > 
> > Why disable security labelling?
> 
> oh, right, that's a bit unrelated. this makes the command work on fedora
> with selinux enabled, otherwise mounting of the glib sources fails there.

Please split that out into a separate commit then. Howcome we didn’t need this before?
Comment 4 Christoph Reiter (lazka) 2018-04-30 11:52:17 UTC
Created attachment 371545 [details] [review]
ci: collect test coverage and deploy a html report through  gitlab pages
Comment 5 Christoph Reiter (lazka) 2018-04-30 11:59:31 UTC
(In reply to Christoph Reiter (lazka) from comment #2)
> (In reply to Philip Withnall from comment #1)
> > Can we have some kind of a crypto signature or SHA512 sum check on the
> > downloaded tarball please? Otherwise if the LTP gets compromised, so does
> > GLib.
> 
> ok

done

(In reply to Philip Withnall from comment #3)
> (In reply to Christoph Reiter (lazka) from comment #2)
> > (In reply to Philip Withnall from comment #1)
> > > ::: .gitlab-ci/run-docker.sh
> > > @@ +8,2 @@
> > >      --file "Dockerfile" .
> > > +sudo docker run --rm --security-opt label=disable \
> > > 
> > > Why disable security labelling?
> > 
> > oh, right, that's a bit unrelated. this makes the command work on fedora
> > with selinux enabled, otherwise mounting of the glib sources fails there.
> 
> Please split that out into a separate commit then. Howcome we didn’t need
> this before?

This script is only needed for debugging the docker container locally and not used by gitlab. I'm usually on debian, which is why I didn't add it initially.
I've just removed it for now.
Comment 6 Philip Withnall 2018-05-01 20:24:02 UTC
Review of attachment 371545 [details] [review]:

Thanks, this looks good to me. I’d like to get Emmanuele’s opinion on it before it’s pushed, though, since he set up the Docker stuff.
Comment 7 Emmanuele Bassi (:ebassi) 2018-05-02 09:38:10 UTC
Review of attachment 371545 [details] [review]:

Nice :thumbsup:
Comment 8 Philip Withnall 2018-05-02 10:16:43 UTC
Fixed a trivial merge conflict and pushed to master, thanks.
Comment 9 Christoph Reiter (lazka) 2018-05-02 12:22:04 UTC
Created attachment 371610 [details] [review]
ci: use timeout-multiplier=2 for running the tests

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.
Comment 10 Philip Withnall 2018-05-02 12:44:18 UTC
Review of attachment 371610 [details] [review]:

yes please