[Buildbot-devel] build consolidation

[Brian Warner]

> For the first build column:  sparc solaris10 gcc trunk.
> 
> 06:44  	tim.peters happened during build 366.
> 06:56  	neal.norwitz happened during the same build 366.
> 
> build 367 started at 06:57 with only tim's changelist, not mine.

Right. With a tree-stable-time of 5 minutes, your 6:56 change was not
eligible for building until 7:01, so it wasn't on the ready list when the
buildslave became free at 6:57 and build#367 started.

> I would like both of the changes to be consolidated. If I understand you
> correctly, the current impl puts them in separate builds by design. If the
> next build started at 07:51 (ie 5 miinutes after my checkin) the changes
> should have been consolidated?

If that next build had started at 7:01 or later, then it would have included
both Tim's change and yours.

The consolidation logic only looks at changes that have passed their
tree-stable-timer. I once considered having it "look ahead" and perhaps delay
the build for a couple minutes in the hopes of incorporating an outstanding
change that was almost ready, but I realized that you could go too far, and a
series of Changes that arrived at just-under-5-minute intervals could prevent
you from ever starting a build.

As an example of the kind of consolidation that it *does* do, take a look at
the far bottom left: Anthony's change[1] at 05:16, your change[2] at 05:24,
and your change[3] at 05:27. All three were incorporated into the solaris
build#365 which began at 05:51. Look at the build's page[4] to see which
changes were included, and look at the SVN revision numbers to confirm that
the build was performed with all of them. (Anthony's change occured just
barely too late to be included in build#364, which started at 05:18.. the
situation is exactly the same as your 06:56 change).

> I think 5 minutes is a reasonable stable-timer for us.  But since our
> tests take over an hour to run, if our changes were 6 minutes apart,
> bb would get further and further behind, unless there is some
> consolidation.  I realize this means the blamelist become less
> effective.  But it means we don't have wait several hours for a
> result.

Yes to everything. The consolidation that the buildbot does is precisely to
avoid an unbounded work queue that would make it fall hopelessly behind. With
the current algorithm, it will never be more than one additional build
behind. The tree-stable timer can wiggle this, but not by more than 5 minutes
or so. (maybe the result is that you can never be more than two additional
builds behind.. I haven't analyzed it with any kind of rigor).

> Hope this makes sense.  Are there any other config options besides the
> stable-timer?

Not that are relevant for SVN. (the other purpose of the tree-stable-timer is
to give you a window where the tree isn't changing, so that if you're dealing
with CVS you can get a safe timestamp to do your checkout with).


cheers,
 -Brian


[1]: http://www.python.org/dev/buildbot/all/changes/1307
[2]: http://www.python.org/dev/buildbot/all/changes/1308
[3]: http://www.python.org/dev/buildbot/all/changes/1309
[4]: http://www.python.org/dev/buildbot/all/sparc%20solaris10%20gcc%20trunk/builds/365