[Buildbot-devel] triggers and builddir.

Wed Aug 19 19:28:11 UTC 2009

Hi Axel, thanks for the clarification; I guess I'd picked up the paradigm from one of the other automation tools.

I'll give your solutions a try.

Thanks again,
Chris J

From: Axel Hecht [mailto:l10n.moz at googlemail.com]
Sent: August 19, 2009 2:39 AM
To: Chris Jarvis
Cc: buildbot-devel at lists.sourceforge.net
Subject: Re: [Buildbot-devel] triggers and builddir.

Hi Chris,

what you're trying to do breaks the paradigms of buildbot a bit, in particular:

Any build can be on any of the slaves registered for that builder.

In your case, you probably only have one slave, for all your builders, and figure "huh"? In case of multiple builds queued, you'll get into trouble in that setup, though, too.

There are basicaly two ways out:

- package results, and ship them between builds
- dynamic factories and a single build
- separate factories and inheritance

Details:

- package results:

For each build, you can add a step that packages the results of that build phase that are required by triggered builds, upload them to a unique-per-build shared location, and pass that location to the triggered build. The triggered build can then download the package to the slave, unpack it and do its deeds. Don't use a single location for all builds, in case multiple builds run at once, you end up overwriting your package, and your triggered builds don't what they're testing.

This setup has the benefit that you're able to rerun tests on existing packages, in particular if they failed for some non-code problem, or you have intermittent issues. It also allows you do keep ETAs for your builds, and at some point to distribute the tests onto special slaves equipped to run special tests that you don't want to set up everywhere. In the mozilla ecosystem, perf tests are run on special slaves to ensure reproducible results, where the slaves for compiles have more flexibility.

The downside is that you likely end up with a staging area having all packages for all builds, which you'll need to peridiocally clobber, likely outside of buildbot itself.

- dynamic factories

In the build factory, you can create different steps depending on build properties, for example. That works nicely and close to what you'd expect. It also gives you a similar amount of code reuse as you get in the builders.

The downsides are that you need to switch off ETAs, and that it's easier to mistake a nightly build for a depend build etc.

- separate factories and inheritance

You get ETAs again, but you end up with more columns in the builder, which can get unwieldy. Also it's somewhat easier to end up with things in release that didn't get tested in the depend builds.

We have all three in our mozilla buildbots, and the pros and cons are my own take on those.

Axel
2009/8/19 Chris Jarvis <chris.jarvis at mobidia.com<mailto:chris.jarvis at mobidia.com>>

Hello,

I'm trying to modularize my build, test and release cycle in such a way as to re-use their definitions between builds. Basically, it's the same scenario discussed in 4.5.7 and 6.1.9 of the buildbot doc; I might want a build that's kicked off for each check, a more thorough build done nightly, and perhaps a third that initiated as needed for a full release cycle.

I've tried to write  my master.cfg to statisfy this need, but had trouble defining the builders. I expected the Builders could be sequenced, and all use the same 'builddir'; because they're run in sequence (each one triggering the next), I'd want my common 'sync' steps to run in the same directory as the 'build'. Alas, master.py enforces a unique builddir for each builder.

Could you supply the builder definitions for the trigger example in the manual?

Regards,

Chris J

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Buildbot-devel mailing list
Buildbot-devel at lists.sourceforge.net<mailto:Buildbot-devel at lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/buildbot-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20090819/f98ab812/attachment.html>