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

[Kreinick, Michael H.]

>> 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 way to communicate (at least not through the default master
>config) between masters that I know of. You can however, use 
>interlocks to kick off sequential slaves, so depending on how 
>you think about it you could set off multiple projects with 
>the same source tree. 

This would work, if the timing actually works (how would we guarantee that
the dependee starts building before the dependent?) but would trigger a
spurious rebuild of the dependee when the dependent changed. Not the end of
the world, but not a very clean solution either.

>> 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.
>
>Could you check it into version control, which would force a 
>get on another master?

No--there would be no way to synchronize the various architectures. Say
we're building on Windows and Solaris; Windows takes twice as long to build.
We would have to arrange somehow for the Windows build to do the CVS touch,
not the Solaris. We really need BuildBot's support for change
handling/merging for this. What if someone does another commit to CVS in the
meantime? It's too much of a kludge.

>> 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.
>
>Is this a coincidence or did you read my post?! :-) (i.e. 
>source keys and filtering)

I wrote it all up last night and, I admit, your message prompted me to
actually send it, but I swear, I came up with it myself :)

>> 3) Add a post-build hook to the master so that dependents could be 
>> notified of a build. Alternatively, I could just subclass 
>BuildMaster.
>
>I think you've pointed out an option that I missed, master build steps.
>Looking at buildbot.process.step there is a Dummy step:
>
>"""I am a dummy no-op step, which runs entirely on the master, 
>and simply
>    waits 5 seconds before finishing with SUCCESS
>    """
>
>this could be modified to allow build steps (e.g. just calling 
>a function in the master.cfg) to allow source filtering etc. 
>If this step had access to the change list (and perhaps other 
>features) it could determine how the build proceeded. This 
>might be useful for your project dependency checking. A 
>problem might be that the build factory has to create build in 
>order for this step to run (only to be aborted if we decided 
>that the filtered changes, or dependencies are not ones you want).
>

Maybe, but a lot of what I suggested sounds like it'll be superseded by the
Scheduler feature Brian mentioned in his response to you. Very interested to
hear more on that. (hint hint)

-Michael