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.comHi 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>