[Buildbot-devel] Buildbot 1.0: The Shimmering Vision

Mark Roddy markroddy at gmail.com
Thu Aug 14 18:47:59 UTC 2008


On 8/14/08, Dustin J. Mitchell <dustin at zmanda.com> wrote:
> On Thu, Aug 14, 2008 at 12:05 PM, Mark Roddy <markroddy at gmail.com> wrote:
>  > Essentially, I have one build slave with a database instance, and two
>  > different builds that need the instance.  There are three steps in
>  > each build that need a lock for the database: Install Schema, Run
>  > Tests, Drop Schema.  I'd need to lock these steps as a whole, and not
>  > lock the steps individually as this creates a race condition.  To work
>  > around this I've been locking the entire build though this is a waste
>  > as prior to these three steps there's about 15 mins of unit tests for
>  > each build that could be executed simultaneously.  Note that if there
>  > is a way to accomplish this already, please let me know.
>
>
> This is not (to my knowledge) currently possible, but my thoughts
>  about configuring builds as microthreaded functions make this easier:
>
>  def do_build(self):
>   lock = self.getLock("foo")
>   yield lock.acquire()
>   try:
>     yield stepa()
>     yield stepb()
>   finally:
>     yield lock.release()
>
>
>  Dustin
>
>  --
>  Storage Software Engineer
>  http://www.zmanda.com
>

I considered creating an "aggregate" step who's only function was to
contain other steps.  That way I could put the lock on the aggregate
step which contained the other steps.  In the end it was a lot easier
to just lock the entire build.  Though as our number of unit tests
increase this is getting to be a bigger issue.

-Mark




More information about the devel mailing list