[Buildbot-devel] triggers and builddir.

[Axel Hecht]

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>

>  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
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20090819/a231285e/attachment.html>