<div dir="ltr">Hi Jon,<div><br></div><div>This is a great idea.</div><div><br></div><div>We can create coverage metrics with gcov / lcov as in this script:</div><div><br></div><div>  <a href="https://github.com/InsightSoftwareConsortium/ITK/blob/d125b69c44ac0ed7d61df0252a6b3b054c60df83/Utilities/Maintenance/computeCodeCoverageLocally.sh">https://github.com/InsightSoftwareConsortium/ITK/blob/d125b69c44ac0ed7d61df0252a6b3b054c60df83/Utilities/Maintenance/computeCodeCoverageLocally.sh</a></div><div><br></div><div>and it looks like lcov has a --diff flag:</div><div><br></div><div>  <a href="http://ltp.sourceforge.net/coverage/lcov/lcov.1.php">http://ltp.sourceforge.net/coverage/lcov/lcov.1.php</a></div><div><br></div><div>A new script (computeCodeCoverageForPatch.sh?) could be created. </div><div><br></div><div>We could run this either with every patch or on demand if it is resource intensive. It may take more effort to figure out a way to post the HTML output and create a link, but it should be doable.</div><div><br></div><div>Thanks,</div><div>Matt </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 17, 2017 at 11:58 AM, Jon Haitz Legarreta <span dir="ltr"><<a href="mailto:jhlegarreta@vicomtech.org" target="_blank">jhlegarreta@vicomtech.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br></div>I'm wondering whether with the current code coverage tools/CI used, and without excessive work and burden, we would be able to spot merge requests or commits that lower the code coverage.<br><br></div>That is, automatically performing a kind of diff between two code coverage reports and identifying the commits (and, thus, the files) that actually make the coverage figure change. Or at least, those that make the figure decrease.<br><br></div><div>If I'm not mistaken some CI tools already provide a coverage report (or at least the figure) for each commit (not 100% sure). I guess that would ideally allow maintainers to take action before a topic or commit makes its way into master.<br><br>For example, that would allow to automatically ask the developer to raise the coverage, or setting some policy to require at least say, a 95% coverage in new files, or to keep the coverage figure when modifying existing files, although this last may be unfeasible in practice. <br><br></div><div>I am well aware that even if this were possible, it would require some investigation. I am ready to help.<br><br></div>Thanks,<br></div>JON HAITZ<br><br clear="all"><div><div><div><div><div><div><div><div class="m_-4465183733691499395gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><table style="color:rgb(0,0,0);font-family:"times new roman";font-size:medium" align="center" cellspacing="0" cellpadding="0" border="0"><tbody><tr><td></td></tr></tbody></table><pre style="color:rgb(0,0,0);white-space:pre-wrap">--<br><br></pre><div><div dir="ltr"></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Community mailing list<br>
<a href="mailto:Community@itk.org">Community@itk.org</a><br>
<a href="http://public.kitware.com/mailman/listinfo/community" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/community</a><br>
<br></blockquote></div><br></div>