[Buildbot-devel] Best practices question: shared code for various buildmasters

[Matthew Morse]

Thanks everyone for the suggestions and pointers!

-- Matt

On Jul 27, 2011, at 6:46 PM PDT, Charles Lepple wrote:

> On Jul 27, 2011, at 5:36 PM, Matthew Morse wrote:
> 
>> I have a bunch of buildmasters running on a host. As their master.cfg files get more sophisticated, I see I've got duplication of routines. I'd like to centralize  those shared routines in one or more modules that can be imported into the various master.cfg files. I'm wondering where best to install those modules. Any suggestions?
> 
> If you use "buildbot reconfig", there are a few pitfalls with import statements. (I think this applies to modules loaded from eggs as well, but I haven't personally used them.)
> 
> You will want a "reload(my_module)" statement after "import my_module". The drawback to reload() is that BuildBot considers the imported modules to be different every time you reconfig, so you get a "configuration updated" message in the waterfall (not so obvious now that the show_events checkbox is off by default). You will probably lose your build ETAs, but I'm not sure if this is true in the most recent 0.8.x releases.
> 
> The part I can't figure out is how to make "from module_foo import bar" work. A reload only seems to update references like "module_foo.bar", not plain "bar". The only recourse there is to run "buildbot restart" instead.
> 
> As far as where to put the modules, I typically put the .py files at the same level as master.cfg (since "." is usually in PYTHONPATH). That way, they are version-controlled with the master.cfg file, and also with any changes to templates or CSS files.
> 
> Another thing to consider is that you don't want to put too much version-specific code into the BuildBot configuration. If you ever want to check out old versions of your code for regression testing, you wouldn't want to have to check out an old master.cfg as well, just to get some build logic that knows how to build the old code.
> 
> -- 
> Charles Lepple
> clepple at gmail