[Buildbot-devel] Hooking a new TCP-listening service into the BuildMaster

[Brian Warner]

On Thu, 31 Jan 2008 15:34:35 -0500
"Dustin J. Mitchell" <dustin at zmanda.com> wrote:

> On Jan 31, 2008 3:14 PM, Greg Ward <gerg.ward+buildbot at gmail.com>
> wrote:
> > But I'm stuck on that "check if a builder is available".  Clearly I
> > need to get my hands on the BuildMaster object.  But my
> > BuildTrigger class is outside the charmed inner circle of
> > Buildbot's own code, even though it'll be running in the same
> > process.  So how do I find my way to the BuildMaster?  I've read
> > enough code that I strongly suspect the answer will involve Twisted
> > services... but I don't quite see how to make it all work.  Hints?
> > Tips?  Advice?
> 
> I've been tossing around the idea of adding a c['extra_services']
> variable to master_cfg.py, which the buildmaster would start at
> application startup.  I don't have the patch handy, but it sounds like
> your question would fit easily into that.

Heh. IStatusReceiver comes to the rescue again.. all status plugins are
attached to the BuildMaster as "service children", so once they've been
started, they can reach the buildmaster through their .parent attribute. In
other words, all IStatusReceiver classes are also supposed to implement
twisted.application.service.IService, and
'statusplugin.setServiceParent(buildmaster)' is executed when the status
plugin appears in the master.cfg file, and your code can do the following:

 from twisted.application import service
 class MyClass(service.Service):
   implements(IStatusReceiver)
   def startService(self):
     service.Service.startService(self)
     print self.parent, "is the BuildMaster"


It isn't the cleanest approach (in an ideal world, status plugins would not
be able to cause builds, and we'd have some different sort of mechanism for
that), but it ought to work.

The c['extra_services'] hook would be a cleaner approach. It could be just
like c['status'] except that it wouldn't assert that the object implements
IStatusReceiver first.. it would just accept anything. The only wrinkle is
that we should decide whether or not c['extra_services'] ought to do the same
compare-before-replacing trick that the rest of the config file does, to
avoid restarting a service that hasn't been modified.

cheers,
 -Brian