<div dir="ltr"><div class="gmail_quote">Hi All,<br>
<br>
In last week's Cross Project IRC meeting [1] I sought to determine the<br>
merits and feasibility of having a central web location for code<br>
coverage of various/all OpenStack projects.<br>
<br>
Presently a few projects add code coverage as a non-voting gate and<br>
that provides a per-commit viewing option, for example [2],[3].<br>
I would first propose after a merge is committed, that coverage that<br>
was generated for the commit is copied to a set and fixed URL so this<br>
can be easily referenced in documentation, etc. (e.g.<br>
<a href="http://coverage.openstack.org/openstack-infra/cover" rel="noreferrer" target="_blank">coverage.openstack.org/openstack-infra/cover</a> and<br>
<a href="http://coverage.openstack.org/openstack/designate/cover" rel="noreferrer" target="_blank">coverage.openstack.org/openstack/designate/cover</a> respectively)<br>
<br>
The purpose of recording code coverage is not to down vote any code<br>
contributions due to lack of code coverage. The purpose includes:<br>
<br>
1. Provide a central location to see current code coverage across<br>
projects, and provide known public URLs.<br>
2. Enable an entry point for discussion of improving code coverage,<br>
especially as a means for newer developers to contribute to projects.<br>
3. To provide analysis of project code coverage by recording coverage<br>
reports over time.<br>
<br>
fungi provided <a href="https://review.openstack.org/#/c/192253/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/192253/</a> which is a<br>
draft spec for a much wider ci-watch effort however I see this a more<br>
specific example. I am seeking feedback from various projects on<br>
interest, concerns and recommendations before creating a spec.<br>
<br>
I see the initial steps to implement this as.<br>
<br>
1. Agree on future domain url location for reports (e.g. <a href="http://coverage.openstack.org" rel="noreferrer" target="_blank">coverage.openstack.org</a>)<br>
2. Add to the merge committing process a step similar to the existing<br>
coverage-log publisher (project-config/jenkins/jobs/macros.yaml) to<br>
agreed location.<br>
3. Provide initially a top level index page at url for published reports<br>
<br>
These steps enable a single current occurrence of code coverage per<br>
project. It is not the objective to keep the historical HTML output.<br>
<br>
Following this, the next steps are to record coverage for historical<br>
analysis with the following.<br>
<br>
1. Alter tox.ini [testenv:cover]  to produce a text based version (aka<br>
coverage report -m).  This is much easier to parse and compare<br>
different versions. I would propose we keep a weekly/daily dated file<br>
of this output, which would be automatically published as per previous<br>
publisher.<br>
2. Use these dated files to produce basic per project analysis of<br>
lines/percentage coverage over time, publishing this to a set<br>
directory structure (e.g. /analysis/) and linked from the top level<br>
index page.  Over time this can be improved to provide simple<br>
graphical output.<br>
<br>
<br>
<br>
[1]  <a href="http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-08-25-21.00.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-08-25-21.00.html</a><br>
[2]  <a href="http://logs.openstack.org/82/165682/8/check/nodepool-coverage/08c6340/cover/" rel="noreferrer" target="_blank">http://logs.openstack.org/82/165682/8/check/nodepool-coverage/08c6340/cover/</a><br>
[3] <a href="http://logs.openstack.org/38/212738/12/check/designate-coverage/bc2e329/cover/" rel="noreferrer" target="_blank">http://logs.openstack.org/38/212738/12/check/designate-coverage/bc2e329/cover/</a><br>
</div><br></div>