Hi Timur, 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), because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc.
On Thu, Jul 2, 2015 at 8:15 PM, Timur Nurlygayanov < [email protected]> wrote: > Hi all, > > 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). > 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. > > we can just copy this job from Rally and start to use it for Sahara: > Coverage control script: > https://github.com/openstack/rally/blob/master/tests/ci/cover.sh > Configuration file for coverage plugin (to exclude code which shouldn't be > affected): https://github.com/openstack/rally/blob/master/.coveragerc > Example of job in infra repository: > https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088 > > I expect that it will help to increase the tests coverage by unit tests. > > Do we have any objections? > > -- > > Timur, > Senior QA Engineer > OpenStack Projects > Mirantis Inc > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Anastasia Kuznetsova
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
