zuul/tests
James E. Blair 9c2985a7e7 Cancel a build even if not found
Canceling a build is naturally subject to race conditions as the
build is started (since canceling a build is different depending
on whether or not it has started).  This has been handled by
checking whether the build has started, and if so canceling the
build, if not, removing it from the queue, and if that fails,
checking to see if the build just started and if so, canceling
that.

But even that is still racy because it's possible for the build
to have started but for zuul to not have received the gearman
packet indicating that it had.  To handle that, simply don't check
whether the build has started for the third attempt.

(The reason we even check at all before the first attempt is that
canceling a running build in jenkins is somewhat expensive (it
involves iterating over all the builds) so it's better to avoid
that if we think it won't work.)

Also, add an extra check in the unit test suite when deciding
whether the system has settled.  This should deal with the case
that a trigger_event -> job transition is happening during the
haveAllBuildsReported check (which only checks jobs).

Change-Id: I60018a5215e7d8230bdf6ef67ec7bc9c719fc286
2014-03-10 16:53:41 -07:00
..
fixtures Cancel obsolete builds on reconfiguration 2014-02-17 13:33:51 -08:00
__init__.py Add non-voting jobs. 2012-08-23 23:20:09 +00:00
test_layoutvalidator.py Support multiple triggers 2013-08-01 11:56:52 -07:00
test_scheduler.py Cancel a build even if not found 2014-03-10 16:53:41 -07:00
test_stack_dump.py SIGUSR2 logs stack traces for active threads. 2013-08-20 15:09:04 -07:00