[Buildbot-devel] Dev / test / production instances of Buildbot?

Trask trask at techsoft3d.com
Mon Jun 18 15:46:31 UTC 2012


In the past 6 months my company has successfully used Buildbot to 
implement continuous builds upon check-in.  It has been a boon to 
turn-around time with build-breakages.  It is a Big Deal.  Responsible 
authors to commits get an email if they break the build.  It didn't take 
long for us fiddling with build steps or file uploads to cause a build 
to fail without it actually being the engineers fault.  Soon the worry 
was Buildbot turning into the "boy who cried wolf" and having engineers 
ignore the email notifications.

Ever since then I have been much more cautious about changes to 
Buildbot; so cautious, in fact, that it hampers productivity.

Has anyone set up parallel instances of their production Buildbot 
instance in order to test changes before using them in production?  I'd 
love to hear how people have done this

My brain-storming with a co-worker lead me to this plan.  It seems a 
little inelegant but should serve the purpose:

My proposed steps to make a "test" instance of Buildbot:
- install a second slave on every slave that currently exists; increment 
port numbers by 1.
- install a second master in the directory "master_test" beside the 
existing "master" location.
- Modify master.cfg to include logic to determine if "isTestInstance." 
Right now I just plan to look at the cwd of master.cfg and see if 
"master_test" is where it lives.  If so, then it is the test instance. 
Within the rest of master.cfg, occasionally the logic will differ 
whether it is the "production" or "test" instance.  For example:
... email notifications enabled in production; disabled in test
... production: schedulers accept changeSources from git triggers; test: 
force builds only
... port numbers for slaves will differ
... webstatus port must differ; etc


We control our Buildbot source files with git.  The "master_test" 
directory would just be another clone of our Buildbot source (primarily 
just "master.cfg" changes).  Pulling changes from the test branches to 
the master branch would be clean.  This method is not ideal for testing 
because the same config file will have different code-paths if it is on 
the test instance versus the production instance, but it is definitely 
better than testing everything in production!

Does anyone have any suggestions before I implement this?  Has anyone 
else done this already?

~Trask




More information about the devel mailing list