[Buildbot-devel] Project dependencies, building branches, etc

[Kreinick, Michael H.]

I'm in a group that has a number of cross-platform products, some of which
are dependent on others. I'm looking at BuildBot for our continuous build
system. I've had success with the basics (build, checkout, cvs integration)
but now I have some more advanced questions. Let me write down my
understanding of the current situation, and then I'll ask my questions.
Please correct me if any of this is wrong.


A master is specific to one project. If you want to build more than one
project, you create more than one master. This is because there's no way to
filter changes, so if you put more than one project on one master, changes
to one will trigger a rebuild of both. Until the upcoming build-on-branches
feature is finished, there is also no way to isolate commits to a particular
builder, so if you have multiple branches of a project, they will all be
rebuilt when any branch is modified. Once the b-o-b feature is finished,
there will be a way to associate builders with a particular branch, and
Changes will trigger only the builders for their branch. Furthermore, slaves
can be connected to only one master. This means that you need #projects *
#platforms slaves.

There is no simple way to handle project dependencies. One possibility would
be to create a BuildStep that would notify other builders to begin building,
but this would be a configuration overhead. They would have to be configured
with the location of the master to connect to and the project to
force-build. This is backwards and creates something of a maintenance
problem; you would expect it to be specified in the dependent project.
Another approach would be to modify BuildBot itself to have a notification
when any build finishes; this could then be used to report to another
instace, which would let its Builders decide which, if any, projects should
be rebuilt.

There is no existing way to aggregate masters' results together. This could
be written relatively easily using the status client APIs to create a web
app that connected to masters to query their status. If it were possible to
get all projects onto one master then the waterfall display could be
trivially modified to display only certain projects.


Okay. With all that said, here's our situation. As I mentioned above, we
have a number of different projects. Each of these projects is built in
multiple variants on multiple OS's, including Windows, Linux, and Solaris.
Some projects depend on others. Not everyone is interested in seeing all
projects; they're categorized and handed off to sub-teams. However, some
teams handle more than one project. Also, some projects have more than one
branch under active development.


Features that we would benefit from include:

Dependencies. When we commit to our utility library A, we want our project B
to be updated to use it. Some projects are tightly integrated and should be
tested in concert this way.

Single master, multiple projects. For a number of reasons, including
simplicity of management and simplicity of configuration, it would be better
for our purposes if we could put all our projects into one master. If we
have to use a master for each product we have, we will be maintaining
multiple sets of BuildBot processes. Also, since there's no way to aggregate
results, there would be no way to get an overall view of the status of all
our products.

Better branch support. I've read the diary posted to this list a while back;
I'm not sure I understand it properly, but my impression is that Builders
can flip between building HEAD and branches arbitrarily. We need builders
configured for each active branch full-time, so that they can build the
appropriate branches when a change comes in.

My proposals:

1) Allow more than one project in a single Master. Support this by adding a
key to each ChangeSource, and letting each Builder define a list of relevant
keys. Once this is done, it would be straightforward to modify the waterfall
display to take a list of builders to display. This would allow for
customized views.

2) Better branch support (from our perspective, I'm not sure how it fits
into the b-o-b feature). This would be fairly simple, except that the change
sources don't appear to report branch information. Once added it would be as
simple as writing a real isBranchImportant function. This ties into (1) and
it might make sense to merge the two features.

3) Add a post-build hook to the master so that dependents could be notified
of a build. Alternatively, I could just subclass BuildMaster.

Having written all of that down, I don't think that it would be too
difficult to do, but I have a somewhat superficial view of the code, and I'm
not sure if it's the cleanest design. Does anyone have any comments? Would
these features be useful to anyone else?

Thanks for reading,
-Michael