[Buildbot-commits] buildbot/buildbot/test test_locks.py,1.2,1.3

Brian Warner warner at users.sourceforge.net
Sat Nov 26 02:14:33 UTC 2005


Update of /cvsroot/buildbot/buildbot/buildbot/test
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10491/buildbot/test

Modified Files:
	test_locks.py 
Log Message:
Revision: arch at buildbot.sf.net--2004/buildbot--dev--0--patch-440
Creator:  Brian Warner <warner at lothar.com>

fix the multiple-equivalent-Lock-instances bug on config-file reload

	* buildbot/locks.py: fix the problem in which loading a master.cfg
	file that changes some Builders (but not all of them) can result
	in having multiple copies of the same Lock. Now, the real Locks
	are kept in a table inside the BotMaster, and the Builders/Steps
	use "LockIDs", which are still instances of MasterLock and
	SlaveLock. The real Locks are instances of the new RealMasterLock
	and RealSlaveLock classes.
	* buildbot/master.py (BotMaster.getLockByID): new method to
	convert LockIDs into real Locks.
	* buildbot/process/base.py (Build.startBuild): convert LockIDs
	into real Locks before building
	* buildbot/process/step.py (BuildStep.startStep): same
	* buildbot/test/test_locks.py (Locks.testLock1a): add a test which
	exercises the problem


Index: test_locks.py
===================================================================
RCS file: /cvsroot/buildbot/buildbot/buildbot/test/test_locks.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- test_locks.py	14 Oct 2005 19:42:39 -0000	1.2
+++ test_locks.py	26 Nov 2005 02:14:31 -0000	1.3
@@ -49,6 +49,11 @@
 c['builders'] = [b1a, b1b, b1c, b1d, b2a, b2b]
 """
 
+config_1a = config_1 + \
+"""
+b1b = {'name': 'full1b', 'slavename': 'bot1', 'builddir': '1B', 'factory': f1}
+c['builders'] = [b1a, b1b, b1c, b1d, b2a, b2b]
+"""
 
 
 class Locks(RunMixin, unittest.TestCase):
@@ -75,7 +80,7 @@
         d = defer.DeferredList([self.req1.waitUntilFinished(),
                                 self.req2.waitUntilFinished()])
         d.addCallback(self._testLock1_1)
-        return d
+        return maybeWait(d)
 
     def _testLock1_1(self, res):
         # full1a should complete its step before full1b starts it
@@ -83,6 +88,27 @@
                              [("start", 1), ("done", 1),
                               ("start", 2), ("done", 2)])
 
+    def testLock1a(self):
+        # just like testLock1, but we reload the config file first, with a
+        # change that causes full1b to be changed. This tickles a design bug
+        # in which full1a and full1b wind up with distinct Lock instances.
+        d = self.master.loadConfig(config_1a)
+        d.addCallback(self._testLock1a_1)
+        return maybeWait(d)
+    def _testLock1a_1(self, res):
+        self.control.getBuilder("full1a").requestBuild(self.req1)
+        self.control.getBuilder("full1b").requestBuild(self.req2)
+        d = defer.DeferredList([self.req1.waitUntilFinished(),
+                                self.req2.waitUntilFinished()])
+        d.addCallback(self._testLock1a_2)
+        return d
+
+    def _testLock1a_2(self, res):
+        # full1a should complete its step before full1b starts it
+        self.failUnlessEqual(self.events,
+                             [("start", 1), ("done", 1),
+                              ("start", 2), ("done", 2)])
+
     def testLock2(self):
         # two builds run on separate slaves with slave-scoped locks should
         # not interfere
@@ -91,7 +117,7 @@
         d = defer.DeferredList([self.req1.waitUntilFinished(),
                                 self.req2.waitUntilFinished()])
         d.addCallback(self._testLock2_1)
-        return d
+        return maybeWait(d)
 
     def _testLock2_1(self, res):
         # full2a should start its step before full1a finishes it. They run on
@@ -107,7 +133,7 @@
         d = defer.DeferredList([self.req1.waitUntilFinished(),
                                 self.req2.waitUntilFinished()])
         d.addCallback(self._testLock3_1)
-        return d
+        return maybeWait(d)
 
     def _testLock3_1(self, res):
         # full2b should not start until after full1c finishes. The builds run
@@ -127,7 +153,7 @@
                                 self.req2.waitUntilFinished(),
                                 self.req3.waitUntilFinished()])
         d.addCallback(self._testLock4_1)
-        return d
+        return maybeWait(d)
 
     def _testLock4_1(self, res):
         # full1a starts, then full1d starts (because they do not interfere).





More information about the Commits mailing list