<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Harald, Everyone,<br>
</p>
<div class="moz-cite-prefix">On 09/04/2019 09.32, Harald Welte
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5cac3c85.1c69fb81.d240a.b479SMTPIN_ADDED_MISSING@mx.google.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
could you outline somewhere (mailinglist? maybe a wiki page?) how
this would work together? </blockquote>
<p>I've started adding code coverage support in changes 13496 and
13551 for OS#1987.<br>
</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:5cac3c85.1c69fb81.d240a.b479SMTPIN_ADDED_MISSING@mx.google.com">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?</blockquote>
<p>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]<br>
</p>
<blockquote type="cite"
cite="mid:5cac3c85.1c69fb81.d240a.b479SMTPIN_ADDED_MISSING@mx.google.com">
<p style="white-space: pre-wrap; word-wrap: break-word;">I would argue it makes more sense to have coverage reports done once per day?</p>
</blockquote>
<p>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.</p>
<p>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.<br>
</p>
<p>BTW I just noticed that libosmocore is not built in the docker
containers.<br>
</p>
<p>Regards,<br>
Vasil<br>
</p>
<p>[1] <a class="moz-txt-link-freetext" href="https://coveralls.io/github/neovim/neovim">https://coveralls.io/github/neovim/neovim</a><br>
[2] <a class="moz-txt-link-freetext" href="https://codecov.io/gh/scrapy/scrapy">https://codecov.io/gh/scrapy/scrapy</a><br>
[3] <a class="moz-txt-link-freetext" href="https://wiki.jenkins.io/display/JENKINS/Cobertura+Plugin">https://wiki.jenkins.io/display/JENKINS/Cobertura+Plugin</a><br>
[4]
<a class="moz-txt-link-freetext" href="https://docs.openstack.org/infra/jenkins-job-builder/publishers.html#publishers.cobertura">https://docs.openstack.org/infra/jenkins-job-builder/publishers.html#publishers.cobertura</a><br>
[5] <a class="moz-txt-link-freetext" href="https://github.com/vlm/asn1c/pull/295#issuecomment-420464856">https://github.com/vlm/asn1c/pull/295#issuecomment-420464856</a><br>
[6]
<a class="moz-txt-link-freetext" href="https://github.com/mouse07410/asn1c/pull/22#issuecomment-298964785">https://github.com/mouse07410/asn1c/pull/22#issuecomment-298964785</a><br>
</p>
<p><br>
</p>
</body>
</html>