[VDSM] Coverage reports

Hi all, Thanks to Edward, we have now coverage reports in jenkins. The way to access the report on jenkins is to use this url: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/<build-number>/artifact/exported-artifacts/htmlcov/index.html Here is an example, hopefully it will be accessible when you try: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifac... Todo: - Easy way to access the report from gerrit It should be easy to add a link the coverage report in the comment added by jenkins after a build finish. - Store the coverage reports for longer time, maybe a week? - We have only 45% coverage instead of the minimum, 100%. Note that coverage of 25% can mean *no* code was run by the tests. The only code running was the functions and class definitions. Here is an example: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifac... Modules that were never imported during the tests have 0% coverage: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifac... - coverage creates lot of useless noise in the jenkins logs, need to slicense this output. http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/console... I did not find a way to do this in nosetests, may need hacking nose coverage plugin. - The report includes only the tests in the tests directory. We have additional tests in lib/vdsm/infra/* which are not included. We should move these to the tests directory. - The report is using absolute paths, but we like shorter relative paths. I don't see a way to configure nosetests or coverage to generate relative paths. May need hacking of the generated html/json in htmlcov. - Add "make coverage" target for running coverage locally - An easy way to enable coverage for the functional tests or for running a single test module. Can be done using nosetests --cover* options. Should be documented in tests/README, and maybe automated using a script or Makefile. When running locally, one would like to have the script open the report in the browser automatically: xdg-open tests/htmlcov/index.html - An easy way to enable coverage when testing flows in vdsm Petr sent a patch for enabling coverage using vdsm.conf: https://gerrit.ovirt.org/49168 We discussed adding vdsm-coverage package that will make it easy to setup Nir

--WK3l2KTTmXPVedZ6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 11/27 20:57, Nir Soffer wrote:
Hi all, =20 Thanks to Edward, we have now coverage reports in jenkins. =20 The way to access the report on jenkins is to use this url: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/<build-n= umber>/artifact/exported-artifacts/htmlcov/index.html =20 Here is an example, hopefully it will be accessible when you try: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/arti= fact/exported-artifacts/htmlcov/index.html =20 Todo: =20 - Easy way to access the report from gerrit It should be easy to add a link the coverage report in the comment added by jenkins after a build finish.
Not really, the gerrit comments that jenkins sends can't be changed by the build, that means that you can't put put there a non-static url. There's a quite tricky way that can be done with groovy postscripts and accessing the jenkins inner objects, but that's very likely to break on any plugin upgrade and requires a bit of investigating with objects to change.
=20 - Store the coverage reports for longer time, maybe a week?
If they are generated with the check patch, you always have the latest there (stored as long as your builds). If you want longer archiving, might be a g= ood idea to generate them too in the check-merged.
=20 - We have only 45% coverage instead of the minimum, 100%. =20 Note that coverage of 25% can mean *no* code was run by the tests. The only code running was the functions and class definitions. Here is an example: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/ar= tifact/exported-artifacts/htmlcov/_home_jenkins_workspace_vdsm_master_check= -patch-fc23-x86_64_vdsm_vdsm_storage_devicemapper_py.html =20 Modules that were never imported during the tests have 0% coverage: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/ar= tifact/exported-artifacts/htmlcov/_home_jenkins_workspace_vdsm_master_check= -patch-fc23-x86_64_vdsm_vdsm_storage_hsm_py.html =20 - coverage creates lot of useless noise in the jenkins logs, need to slic= ense this output. http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/co= nsoleFull I did not find a way to do this in nosetests, may need hacking nose coverage plugin. =20 - The report includes only the tests in the tests directory. =20 We have additional tests in lib/vdsm/infra/* which are not included. We should move these to the tests directory. =20 - The report is using absolute paths, but we like shorter relative paths. =20 I don't see a way to configure nosetests or coverage to generate relative paths. May need hacking of the generated html/json in htmlcov.
If you find it please tell me, I have the same issue with other projects, I= 'll do if I discover a way :)
=20 - Add "make coverage" target for running coverage locally =20 - An easy way to enable coverage for the functional tests or for running a single test module. =20 Can be done using nosetests --cover* options. Should be documented in tests/README, and maybe automated using a script or Makefile. When running locally, one would like to have the script open the report in the browser automatically: xdg-open tests/htmlcov/index.html =20 - An easy way to enable coverage when testing flows in vdsm =20 Petr sent a patch for enabling coverage using vdsm.conf: https://gerrit.ovirt.org/49168 We discussed adding vdsm-coverage package that will make it easy to set= up =20 Nir
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605 --WK3l2KTTmXPVedZ6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWWK0AAAoJEEBxx+HSYmnDRZQIAJSjT1HUI0OVV29vhBQ2UqXP jxfiAe+3XjGCBNa6mCmSbv4KSV6mivJYsjk0dq+hh88UzBhJ1IRBhW5nYPx8PaYH y6DdDt8E9IeXWDWjVDdkOMUeDoajcuTaOKoU0HKbYkYx59y6hugtAmYi2r1kU+jT 2ZPweulBTtvq2DzT3IXVkKwqzvR7TdHy9/IGAsENmCrLyG4ZSNlBQwTinwj4qNjC Nrs0/uUewcL/AbL6t7buSSyE8PvB7oaU6KbwZ4dz1mFEWFVZbIa3QFpTrX6k305R l1CWggj0rAisl3ka1ubM3QuvgRESrgjhLWtq9Eqrp8fwYNAFawbiQJmvzP3bZy0= =DV50 -----END PGP SIGNATURE----- --WK3l2KTTmXPVedZ6--

On Fri, Nov 27, 2015 at 9:20 PM, David Caro Estevez <dcaro@redhat.com> wrote:
On 11/27 20:57, Nir Soffer wrote:
Todo:
- Easy way to access the report from gerrit It should be easy to add a link the coverage report in the comment added by jenkins after a build finish.
Not really, the gerrit comments that jenkins sends can't be changed by the build, that means that you can't put put there a non-static url. There's a quite tricky way that can be done with groovy postscripts and accessing the jenkins inner objects, but that's very likely to break on any plugin upgrade and requires a bit of investigating with objects to change.
The url for the coverage report is the build url we see in gerrit + ' /artifact/exported-artifacts/htmlcov/index.html <http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifact/exported-artifacts/htmlcov/index.html> ' Maybe this can be added by a gerrit plugin? Another option - can we add nice "coverage" link to jenkins build page? One click on the build link from gerrit, and another on the build page is better then typing the url manually.
- The report is using absolute paths, but we like shorter relative paths.
I don't see a way to configure nosetests or coverage to generate relative paths. May need hacking of the generated html/json in htmlcov.
If you find it please tell me, I have the same issue with other projects, I'll do if I discover a way :)
I found this json, which looks like something that can be easily hack: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/665/artifac... I did not try, but maybe modifying "relative_filename" will do the trick. We can wrap coverage with our own script creating a report and cleaning it up. Nir

The url for the coverage report is the build url we see in gerrit + '/artifact/exported-artifacts/htmlcov/index.html'
Maybe this can be added by a gerrit plugin?
Another option - can we add nice "coverage" link to jenkins build page?
One click on the build link from gerrit, and another on the build page is better then typing the url manually.
Well, you can click your way like this: Gerrit comment -> job results -> Build Artifacts -> exported-artifacts -> htmlcov/ But this is not optimal, maybe we could improve the CI standard so that a certain artefact file gets posted on the Jenkis results page. -- Barak Korren bkorren@redhat.com RHEV-CI Team

Awesome! Infra stakeholders - any chance to have this pushed to the devel list once a month (or some other reasonable period)? On Fri, Nov 27, 2015 at 8:57 PM, Nir Soffer <nsoffer@redhat.com> wrote:
Hi all,
Thanks to Edward, we have now coverage reports in jenkins.
The way to access the report on jenkins is to use this url: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/ <build-number>/artifact/exported-artifacts/htmlcov/index.html
Here is an example, hopefully it will be accessible when you try:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifac...
Todo:
- Easy way to access the report from gerrit It should be easy to add a link the coverage report in the comment added by jenkins after a build finish.
- Store the coverage reports for longer time, maybe a week?
- We have only 45% coverage instead of the minimum, 100%.
Note that coverage of 25% can mean *no* code was run by the tests. The only code running was the functions and class definitions. Here is an example:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifac...
Modules that were never imported during the tests have 0% coverage:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifac...
- coverage creates lot of useless noise in the jenkins logs, need to slicense this output.
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/console... I did not find a way to do this in nosetests, may need hacking nose coverage plugin.
- The report includes only the tests in the tests directory.
We have additional tests in lib/vdsm/infra/* which are not included. We should move these to the tests directory.
- The report is using absolute paths, but we like shorter relative paths.
I don't see a way to configure nosetests or coverage to generate relative paths. May need hacking of the generated html/json in htmlcov.
- Add "make coverage" target for running coverage locally
- An easy way to enable coverage for the functional tests or for running a single test module.
Can be done using nosetests --cover* options. Should be documented in tests/README, and maybe automated using a script or Makefile. When running locally, one would like to have the script open the report in the browser automatically: xdg-open tests/htmlcov/index.html
- An easy way to enable coverage when testing flows in vdsm
Petr sent a patch for enabling coverage using vdsm.conf: https://gerrit.ovirt.org/49168 We discussed adding vdsm-coverage package that will make it easy to setup
Nir _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

On 2 December 2015 at 12:21, Allon Mureinik <amureini@redhat.com> wrote:
Awesome!
Infra stakeholders - any chance to have this pushed to the devel list once a month (or some other reasonable period)?
I see a few possible ways to get this: 1. Run the same code in 'check_merged.sh' followed by some code to mail the results. With the whole thing surrounded by some conditional to decide if the time to send a new report had come. (One possibility is every X merged patches since the last release) 2. Devise some extension the the CI standard to let you specify periodic jobs. 3. Send a YAML patch to create a new stand-alone job. (That, experience shows, would result in that job being unmaintained) -- Barak Korren bkorren@redhat.com RHEV-CI Team

I think a weekly job that store the results for a couple of weeks would be nice. Will give us easy way to look at progress with very little load on the servers and minimal storage requirements. On Thu, Dec 3, 2015 at 10:51 AM, Barak Korren <bkorren@redhat.com> wrote:
On 2 December 2015 at 12:21, Allon Mureinik <amureini@redhat.com> wrote:
Awesome!
Infra stakeholders - any chance to have this pushed to the devel list once a month (or some other reasonable period)?
I see a few possible ways to get this:
1. Run the same code in 'check_merged.sh' followed by some code to mail the results. With the whole thing surrounded by some conditional to decide if the time to send a new report had come. (One possibility is every X merged patches since the last release)
2. Devise some extension the the CI standard to let you specify periodic jobs.
3. Send a YAML patch to create a new stand-alone job. (That, experience shows, would result in that job being unmaintained)
-- Barak Korren bkorren@redhat.com RHEV-CI Team
participants (4)
-
Allon Mureinik
-
Barak Korren
-
David Caro Estevez
-
Nir Soffer