[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