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

"Martin v. Löwis" martin at v.loewis.de
Wed Dec 28 19:45:45 CET 2005

Jean-Paul Calderone wrote:
> A slave is an entity capable of performing tasks.  It can be 
> asked to perform any task you like, though it may not be able 
> to perform them all if it lacks some requirements.

This is clear in principle. However, what constitutes a "task"?
I see that you can send it shell commands to execute, arbitrary
ones, with environment variables. What else? Can you send it
Python code?

> A builder is a particular job.  It can be performed by any 
> slave (so long as its requirements are met), or by multiple 
> slaves.

That I'm not so sure of. In a builder, I give a single value
"slavename", and I understand that only that single slave will
ever get jobs from the builder - not any slave. I also read
that I can give "slavenames" instead, but that I should do so
only if the slaves are sufficiently similar (for some metric
which I apparently have to define myself).

> A factory defines the work to be done by a builder.  If which 
> compiler is being used is an important part of the purpose of 
> a builder (for example, there might be a builder the purpose of 
> which is to test a Python built with GCC 3.4 and another the 
> purpose of which is to test a Python built with GCC 4.0), then 
> it should be specified in the master configuration.  If it is 
> not important, then it should be left as general as possible, 
> to allow for the most slaves to be able to complete the task.

So would the assumption be that I use the same factory for
multiple builders? I'm gravitating towards a 1:1:1 relationship
between factories, builders, and slaves. For example, on OSX,
I think I have to give --with-suffix=.exe to configure. This
means I have to create a separate factory, which then only
applies to OSX builders (of which I have only one), which
has just a single slavename.

> I have most often seen branches supported by allowing commits 
> to trunk to automatically trigger a build on trunk, while 
> commits to branches do not automatically trigger any builds.

I think I want it differently: commits to release24-maint should
also trigger builds; commits to other branches should not trigger
builds. Does that mean I need twice as many builders? How
do I tell them what branch they should build?

> Builds on branches can then be explicitly requested when a 
> developer wants to know the state of their branch on various 
> platforms/configurations (often before merging to trunk to 
> know if they are introducing any regressions, but valuable 
> at other times as well).

Some people advised me that supporting web-initiated builds
is not a good idea. So I turned off all manual triggering of
builds for now. I would like to give committers permission to
trigger builds, but I'm not sure how to do that.

> I think this means tags/release24-maint won't ever be built 
> automatically (I haven't used AnyBranchScheduler, and I don't 
> know much about schedulers in buildbot in general).  You 
> should be able to manually request a build, but for some 
> reason I don't see the form for doing so on the master website 
> (<http://twistedmatrix.com/buildbot/full-2.3> for an example 
> of what this looks like).  I'm not sure if this is a buildbot
> version problem, or if there is just another piece of 
> configuration that needs to be set.

Ah, no: that's configuration that would need to be removed.
Jeff Pitmann suggested that this feature be disabled
(Waterfall(allowForce=False)). Before I did that, there
was indeed a form to request building of a branch.


More information about the Python-Dev mailing list