[Buildbot-devel] Some questions/problems running latest build bot source on Windows

[Brian Warner]

> |My employer may be able to help with that; I've suggested it before
> |and got a positive response. Unfortunately we wouldn't be able to give
> |you access to the build machine, but we could get the build results
> |mailed.

Fortunately, that's almost exactly the way the buildbot is designed. The
slaves initiate TCP connections to the master, so they can live behind NAT
boxes or what-have-you. As long as the slave can connect to the master,
perform the CVS/SVN/etc retrieval, and run the commands necessary to do the
build, then it can contribute to the project as a whole.

Using email as a transport layer would be harder.. the current buildslave is
(by design) pretty dumb, it just runs a series of commands sent to it by the
master. This keeps the configuration centralized in the buildmaster, reducing
the number of people who have to be involved in a change of build process.
Representing that set of commands (and the usually-realtime responses to
them) in an email message would be a significant change. Incidentally, this
is how Tinderbox does it, if I understand it correctly.

One thing to keep in mind is that, by allowing a build of project X to be run
in your user account (or on your machine), you are effectively giving full
access to your account (and machine) to everyone who has commit access to
project X. It doesn't matter whether the slave has a realtime connection to
the outside world or not, running 'make all' in their tree is giving them
control over that account. Depending upon your relative levels of trust and
vulnerability, this decision may not be compatible with your overall security
policy. It is quite reasonable to run the buildslave in a chroot environment
or on a machine in the DMZ, if that slave is running code on behalf of people
outside your organization. On the other hand, i your organization may already
be trusting code from those same developers (by using a released version of
it), so you may not have any increased exposure by trusting their -HEAD
version as well.


> [elliot] 
> 
> For what it's worth, this is a use case that I am *very* interested in;
> allowing people to submit results from disconnected or loosely connected
> machines and have those results folded into the buildmaster status display.
> This type of support makes it much easier for projects to get assistance
> with builds/tests from people at other companies/sites who would be willing
> to contribute compute cycles but are not allowed to open up access to the
> build machine.

Yes, exactly. Especially because the specific kind of testing the buildbot
was created for (portability testing across multiple platforms) is also the
kind that's the hardest to accomplish within your own organization. Most
companies tend to be pretty homogeneous, and most free-software projects tend
to be pretty under-staffed, so lowering the "bar to contribution" is pretty
important.


We'll have to ponder that more-disconnected case further, we might be able to
build something that handles it. Twisted has extremely broad protocol
support, so we aren't limited to realtime-TCP connections.. it's just a
question of deciding how we want to use the other protocols. The biggest
problem that I see is that a machine which can't (or isn't allowed to) make a
TCP connection to the buildmaster is unlikely to be able to make a TCP
connection to the VC repository. For small projects, the buildmaster could
conceivably tar up a copy of the current sources and email it (hmm.. or a
patch relative to the last version that was sent), but that could get
unwieldy awfully quick. I'm inclined to let CVS/SVN/Arch/etc do their jobs
and keep the Buildbot out of that space :).

thanks,
 -Brian