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

"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.

Regards, Martin

More information about the Python-Dev mailing list