[Buildbot-devel] Buildbot 1.0: The Shimmering Vision

Kinneberg, Steve stevek at qualcomm.com
Thu Aug 7 23:13:26 UTC 2008


> -----Original Message-----
> From: buildbot-devel-bounces at lists.sourceforge.net 
> [mailto:buildbot-devel-bounces at lists.sourceforge.net] On 
> Behalf Of Dustin J. Mitchell
> Sent: Wednesday, August 06, 2008 10:07 AM
> To: buildbot
> Subject: [Buildbot-devel] Buildbot 1.0: The Shimmering Vision
> 
> It's clear that there's some pent-up excitement about what Buildbot
> can be, and enough development muscle behind that to make it a
> reality.  Last night, I gave a presentation to ZPUGDC
> (http://zpugdc.org/) that also generated a lot of interest.  It's time
> to start thinking about Buildbot-1.0.  I think we should approach this
> as Guido has approached Py3K: start with a vision, keep backward
> compatibility where possible, and dispense with it where it's a
> distraction.
> 
> What will 1.0 look like, from a user's perspective?  Let's hash this
> out on the list, come up with a brief description, and then put it on
> the wiki and lay out some milestones to get there.
> 
> I'll start, but of course my opinion is not authoritative.
> 
> Buildbot 1.0 is a framework for building distributed testing systems
> (so users write a buildbot *program*, rather than configuring
> buildbot).  It has a solid distributed job control system capable of
> sophisticated job scheduling and control.  It has a scalable
> persistence backend for storing build results, with an expandable
> schema.  It ships with a bunch of components, and makes it easy to
> plug in more: version-control interfaces, build processes,
> notification systems, displays, and control.  It uses normal software
> abstraction techniques to make the basic use-cases easy.
> 
> Dustin
> 

Here's a couple thing I think would be nice (or if they can already be
done with 0.7.8, then a little education on how to accomplish these
wishlist items):

- The ability to aggregate the individual build result and log files
from triggered builds into the build status for the builder that did the
triggering.  We build several branches for a few platforms for a couple
projects.  By aggregating the build results we can greatly reduce the
amount of email generated making it more likely that our developers will
read the emails.

- The ability to copy log files on a file server outside Buildbot.

- Second Neil Hemingway's request to make viewing build results on per
branch basis easier (default?).

- Ability to specify build properties via the web page when doing a
force build from the web page.

- For nightly schedulers (and any other non-triggerable, non-commit
schedulers), include the changes in the build results since the last
time that build was done.

- Add intrinsic file operation commands that the slave will do rather
than using ShellCommmand for things like "cp", "rm", "tar", etc.  For
some people, this could remove the need for tools like Cygwin when
building cross-platform.

Thanks,
Steve Kinneberg




More information about the devel mailing list