Igor, it is much more clear for me now. Thank you :)
On Fri, Nov 20, 2015 at 2:09 PM, Igor Belikov <ibeli...@mirantis.com> wrote: > Hi Stanislaw, > > The reason behind this is simple - deployment tests are heavy. Each > deployment test occupies whole server for ~2 hours, for each commit we have > 2 deployment tests (for current fuel-library master) and that’s just > because we don’t test CentOS deployment for now. > If we assume that developers will rertrigger deployment tests only when > retrigger would actually solve the failure - it’s still not smart in terms > of HW usage to retrigger both tests when only one has failed, for example. > And there are cases when retrigger just won’t do it and CI Engineer must > manually erase the existing environment on slave or fix it by other means, > so it’s better when CI Engineer looks through logs before each retrigger of > deployment test. > > Hope this answers your question. > > -- > Igor Belikov > Fuel CI Engineer > ibeli...@mirantis.com > > On 20 Nov 2015, at 13:57, Stanislaw Bogatkin <sbogat...@mirantis.com> > wrote: > > Hi Igor, > > would you be so kind tell, why fuel-library deployment tests doesn't > support this? Maybe there is a link with previous talks about it? > > On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov <ibeli...@mirantis.com> > wrote: > >> Hi, >> >> I’d like to inform you that all jobs running on Fuel CI (with the >> exception of fuel-library deployment tests) now support retriggering via >> “recheck” or “reverify” comments in Gerrit. >> Exact regex is the same one used in Openstack-Infra’s zuul and can be >> found here >> https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/global.yaml#L3 >> >> CI-Team kindly asks you to not abuse this option, unfortunately not every >> failure could be solved by retriggering. >> And, to stress this out once again: fuel-library deployment tests don’t >> support this, so you still have to ask for a retrigger in #fuel-infra irc >> channel. >> >> Thanks for attention. >> -- >> Igor Belikov >> Fuel CI Engineer >> ibeli...@mirantis.com >> >> >> >> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
