<div dir="ltr">Anastasia, <div><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc.</blockquote></div><div><br></div><div>This job compares amount of non covered lines (before and after patch).</div><div>If you just remove code there will be less lines that should be covered so amount of non covered lines will be less or the same (if everything was covered before)</div><div><br></div><div>Fixing typos in docstrings won't introduce new lines. </div><div><br></div><div>Btw job allows you to introduce  N (few) new lines that are not covered by unit tests that are uncovered in some cases. </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 10:46 AM, Anastasia Kuznetsova <span dir="ltr"><<a href="mailto:akuznetsova@mirantis.com" target="_blank">akuznetsova@mirantis.com</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">Hi Timur,<div><br></div><div>Generally I think that it is a good idea to have a gate that will check whether new code is covered by unit tests or not. But I am not sure that this gate should be voting (if I understand you correct),</div><div>because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 2, 2015 at 8:15 PM, Timur Nurlygayanov <span dir="ltr"><<a href="mailto:tnurlygayanov@mirantis.com" target="_blank">tnurlygayanov@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div><div>Hi all,<br><br></div>I suggest to add CI 
job which will check the unit tests coverage for Sahara repository and 
will set -1 for commits with new code and without unit tests (if we have
 some degradation of tests coverage).<br></div><span>This job successfully 
works for Rally project and it helps to organize the right code 
development process when developers write new unit tests for new 
functionality.<br><br></span></div>we can just copy this job from Rally and start to use it for Sahara:<br></div><span>Coverage control script: <a href="https://github.com/openstack/rally/blob/master/tests/ci/cover.sh" target="_blank">https://github.com/openstack/rally/blob/master/tests/ci/cover.sh</a><br></span></div><span>Configuration file for coverage plugin (to exclude code which shouldn't be affected): <a href="https://github.com/openstack/rally/blob/master/.coveragerc" target="_blank">https://github.com/openstack/rally/blob/master/.coveragerc</a><br></span></div><span>Example of job in infra repository: <a href="https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088" target="_blank">https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088</a><br clear="all"><div><br></div>I expect that it will help to increase the tests coverage by unit tests.<br><br>Do we have any objections?<br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#888888"><font color="#888888"><br></font></font><div style="font-family:arial;font-size:small">Timur,</div><div style="font-family:arial;font-size:small">Senior QA Engineer</div><div style="font-family:arial;font-size:small">OpenStack Projects</div><div style="font-family:arial;font-size:small">Mirantis Inc</div></div></div></div></div></div></div>
</span></div>
<br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Best regards,<div>Anastasia Kuznetsova</div></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>