[Buildbot-devel] Recommendations...

BRM bm_witness at yahoo.com
Tue Sep 20 21:59:13 UTC 2011

I'm presently converting my existing autobuilds - which utilize an old DOS Batch script run via the Windows Scheduler - to BuildBot.
Presently I only have 1 Windows computer that can run builds (and won't likely be getting another anytime soon), which is where I setup BuildBot with a master and a single slave.
In testing the builds, I've overloaded the system a little - one build failed as the build did not communicate in 1200 seconds, probably b/c I had 12 builds running at the same time under a single slave.
So, what is the normal approach for divvying up builds? Do you recommend one build-slave per processor/core? Or does it not matter so much?
How many builds per build slave is normal or do you expect for normal?

Presently I am just forcing builds as I want to make sure each project works in an expected manner as I move it over - I've been overloading it a little as I have a lot of projects to move into the system (which also exposes a few weaknesses in Buildbot, but I can deal with that for now...perhaps I'll cover that in another email later...). So I'm not surprised at the moment that I had one fail due to time constraints.

I'm planning on using scheduled builds (once/day) for the time being, and probably adding some on-demand builds for new releases in the future (to automatically build new "tags" to the 'tags' folder in SVN...if I can work out how to do that one...but that's down the line a bit).

Any how...I'd like to hear from you all what recommendations are for use so I can have some expectations on how to run/schedule things. I've been quite impressed thus far with Buildbot in many ways - including how many builds I've been able to get going at once under a single build slave, though I don't know that is really kosher to do.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20110920/8156f8a1/attachment.html>

More information about the devel mailing list