9c2985a7e7
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 |
||
---|---|---|
.. | ||
__init__.py | ||
gearman.py |