Code coverage reports in Jenkins

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Vasil Velichkov vvvelichkov at gmail.com
Tue Apr 9 12:49:36 UTC 2019


Hi Harald, Everyone,

On 09/04/2019 09.32, Harald Welte wrote:
> could you outline somewhere (mailinglist? maybe a wiki page?) how this 
> would work together? 

I've started adding code coverage support in changes 13496 and 13551 for 
OS#1987.

Initially my goal was to generate reports only manually using gcov and 
lcov tools but after submitting my first change to gerrit I've noticed 
that Jenkins is used for CI/CD so I thought that it might be useful to 
generate these reports as part of the CI process. Jenkins has a 
Cobertura plugin [3] which collects coverage data in XML format [4], 
visualize them and track coverage metrics over time/builds. I've used 
lcov_cobertura tool to convert the lcov's coverage format to XML.

> This Dockerfile which you're patching is used for build verification 
> of gerrit patches. Do you want to run coverage reports on every build 
> of every patch before commit?

Yes, that was my idea. Other projects that I've used or contributed to 
in the past are using a workflow where code coverage data is generated 
in every CI build, then send to a coverage service, which analyze them 
and post message back in the PR about the coverage results - whether the 
coverage has increased, decrease, diff between reports, etc...   For 
example see [1], [2], [5], [6]

> I would argue it makes more sense to have coverage reports done once 
> per day?
>
In my opinion the coverage reports are more useful when they are closely 
integrated into the code review process and you receive information how 
coverage has changed together with the build status in the code review 
system. When reviewing a change the report could gives you more insights 
but still you should be able to merge it no matter what the coverage 
report says.

If you find these reports not very useful during the code review process 
or the changes too disruptive to your workflow then we could build them 
once per day in the Osmocom_OBS_nightly (or another) job or not build 
them at all in the CI.

BTW I just noticed that libosmocore is not built in the docker containers.

Regards,
Vasil

[1] https://coveralls.io/github/neovim/neovim
[2] https://codecov.io/gh/scrapy/scrapy
[3] https://wiki.jenkins.io/display/JENKINS/Cobertura+Plugin
[4] 
https://docs.openstack.org/infra/jenkins-job-builder/publishers.html#publishers.cobertura
[5] https://github.com/vlm/asn1c/pull/295#issuecomment-420464856
[6] https://github.com/mouse07410/asn1c/pull/22#issuecomment-298964785


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190409/9b3a8afd/attachment.htm>


More information about the OpenBSC mailing list