I completely agree that the expectation should be that all CI systems
pass consistently on a good patch. The problem is this isn't the case.
For people fighting the dozens of CI systems on nova or neutron this
causes a real problem. Where issuing rechecks will eventually get the
good state and while doing so puts the 1st party or some other CI out of
a good state.
While we are battling these race conditions and simply unstable systems
I feel it would be good to be able to kick specific ones to help things
move along faster. The reduced load on all CI's is an added benefit.
Cheers,
Josh
Rackspace Australia
On 8/12/14 11:17 PM, Jeremy Stanley wrote:
On 2014-08-12 17:43:37 +1000 (+1000), Joshua Hesketh wrote:
Right, and even if we did change all the 3rd parties over to
something that doesn't start with 'recheck' there will be
inconsistencies between 3rd parties and 1st party.
[...]
If this is really something the various CI operators want to support
(rather than merely something which has been cargo-culted as a
behavior they're expected to emulate), I think we need a separate
syntax for it which lacks the encumbrance of the currently ambiguous
"recheck" ad-hoc language which has grown arbitrarily by convention.
However, I also don't personally think that rechecking one specific
CI makes sense, and would rather just have them all run every time
you say "recheck" since otherwise you end up pin-and-tumbler
lockpicking racy bugs (selectively rerererecheck each CI until you
get a good run and then hold that result while you work through the
rest of them in turn).
I'm less worried about the small amount of resource waste in the
upstream OpenStack project infrastructure from people getting jobs
rerun when they recheck for some failed third-party result. The
expectation we ultimately need to set is that every CI should pass
pretty much all of the time on a good change and if it doesn't then
it must be fixed (upstream CI included). Allowing you to selectively
rerun jobs from one system reinforces the idea that it's okay to
fail frequently as long as devs are eventually able to coax out a
passing run.
_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
