[Python-Dev] Automated Python testing (was Re: status of development documentation)

[Jean-Paul Calderone]

On Sun, 25 Dec 2005 16:54:44 -0800, Brett Cannon <bcannon at gmail.com> wrote:
>On 12/25/05, Tim Peters <tim.peters at gmail.com> wrote:
>> [Tim]
>> >> Take a look at:
>> >>
>> >>     http://buildbot.zope.org/
>> >>
>> >> That runs code from:
>> >>
>> >>     http://buildbot.sourceforge.net/
>> >>
>> >> Someone sets up a "buildbot master" (that's what the Zope URL points
>> >> at), and then any number of people can volunteer to set up their boxes
>> >> as "buildbot slaves".
>>
>> [Brett]
>> > As in some machine I might personally have left on?
>>
>> Slaves have to be powered on to work, yes ;-)
>>
>> > That would require a static IP which I don't know how common that
>> > will be.
>>
>> Spend a few minutes skimming the buildbot docs -- I'm not an expert,
>> but it's a real system in real use, and they have solutions for the
>> obvious problems.  In this case, while the master passes out commands
>> to run and collects status, a slave _initiates_ communication with the
>> master.  A static IP for the master is good for that, but I figure the
>> slave can keep participating happily then for just as long as it can
>> keep a socket connection open with the master.
>>
>
>OK, so it is a pull from the slave side, not a push on the master side.
>
> [snip]
>
>See, that is what threw me; thinking that when the master knows a
>change happens it pushes out to the slaves.  I guess the master notes
>that there is a reason to do a new run and that is what the slaves are
>constantly checking with the master about.

The whole world isn't HTTP.  There is not necessarily any correlation 
between the party which initiates the TCP connection and the party 
which instigates a run.  Slaves connect to the master when they come 
online.  The master uses that connection to push commands to the slaves 
at the appropriate time.

Buildbot also supports having multiple slaves perform runs (or "builds", 
in buildbot terminology) for a particular configuration.  This means 
that several people can cooperate to give full coverage for a particular 
platform, even if none of them can leave a machine on 24/7.  You really 
do want 24/7 coverage for a supported platform, because utility declines 
rather rapidly as you fall short of this.  Developers tend to have an 
amazing knack for committing broken changes when the slave which would 
have noticed them is offline :)

Jean-Paul