[Buildbot-devel] Extra level of abstraction for build failures

[Shaun McDonald]

Hi,

First up, there are two types of build failure. First is a problem  
with the buildbot, such as when there has been a short (or long)  
connection interruption of as little as a minute. Developers don't  
want to know about this failure, though build slave maintainers do.  
Second is a real problem with the source code, and something that  
developers want to know about.

In the OpenOffice.org project it is now the case that a build failure  
of a branch on a buildbot or tinderbox, can prevent the integration of  
the particular branch. Unfortunately it has been a problem where the  
build has failed due to the branch being based on some bad milestone,  
or there was an interruption during the build (rather easy when builds  
take around a day on older/slower machines).

What we introduced was a fold status for the tinderbox mails. This was  
helped with a custom shell build script to set the status, and a  
custom tinderbox script. (These were both on the master). However we  
never managed to get the fold status to be sent for builds that failed  
due to the build slave going offline. We also had a problem with build  
steps showing yellow instead of the defined grey for a skipped step or  
even build.

I'm currently wondering if it would be useful for other projects to  
have this level of abstraction, where it is clear which type of  
failure that has occurred. (i.e. one for developers or build slave  
maintainers need to be aware of). Would it be useful to have his  
upstreamed?

The code was done through sub classing:
http://ootermite.googlecode.com/svn/trunk/buildbot/buildmaster/OOtinder.py
http://ootermite.googlecode.com/svn/trunk/buildbot/buildmaster/OOShell.py


Shaun