Hi,
To setup my own Subversion Build & Test farm, I spent some time this weekend
to install buildbot (http://buildbot.sourceforge.net/) on my server. It's
currently configured to build svn trunk and branches/1.3.x with the purpose
of testing my patches on Linux and Mac OS X.
I know that kfogel started with defining a buildbot-based B&T farm
(http://subversion.tigris.org/build-farm.html), but he told me yesterday he
lacks the time to finish it in the near future.
Since my 'farm' is now installed and I'll keep it online anyway, as far as
I'm concerned it can serve as a (temporary) Build & Test farm solution for
the Subversion project. Atleast it'll show us the benefits and disadvantages
of using buildbot, in preparation of a setup hosted by CollabNet.
This is the current configuration:
1. The buildmaster is installed on a VPS running FC1. It has an internal
webserver listening on an internal port. Apache serves as a reverse proxy.
The server is hosted in a datacenter in Amsterdam (The Netherlands).
2. The build page is located here: http://www.mobsol.be/buildbot/ . I setup
a virtual host here: http://svnbuildbot.mobsol.be, but that subdomain was
only configured a few hours ago so it'll probably not resolve yet.
3. You see on the build page that I have two slaves attached to the
buildmaster. One of them is running on the same VPS as the buildmaster
(Linux/FC1), the other one is installed on my Mac (OS X 10.4).
4. My buildbot user is subscribed to the svn mailing list (commit emails). I
wrote some code to parse the branch, name, timestamp, revision and log
message from the commit email. That information is used to decide whether
the commit needs to trigger a rebuild, and which slaves need to be
activated.
After each commit on the svn repository the buildmaster waits 10 minutes.
This delay was needed with CVS to make sure all file commits were finished,
but I use it to group some changesets. A normal build&test takes some 50
minutes, so I don't want it to trigger that often.
5. The buildmaster manages the build and test steps for each slave. I now
use the normal autogen.sh -> configure -> make -> make check cycle, but
these things can be customized per slave. An alternative is to use one
script on a fixed location on the slave, so the slave-owner can customize it
as needed.
6. I'm not going to activate the option to send mails to committers who make
the build fail :)
7. I've installed a TryScheduler as well. The TryScheduler is used to
trigger manual builds, with custom patches not yet committed to the svn
repository: "What would happen if I committed this patch right now?".
To use the TryScheduler, developers need the buildbot client and a
username/password to connect to the buildmaster.
There are some problems still in this area, to name a few:
- 'buildbot try' uses svn diff on the local working copy to calculate the
patch compared to current trunk. I tried it with my patch for issue #2475,
which adds a new python test path_tests.py. The TryScheduler checkouts trunk
and applies the patch, but in this example it fails to make the
path_tests.py executable, so the test won't run. Since svn diff cannot
express propset svn:executable I'll have to find out a workaround.
- I had to patch the 'buildbot try' client to make it work on Windows, don't
know how it behaves on Linux.
- 'buildbot try' will always build your exact working copy, so if you didn't
update for a few days, it'll checkout trunk and then apply a full patch to
make it match your working copy.
The way buildbot works raises some questions on how to organize slaves, and
how to solve problems.
For example:
- while the build page will show which tests failed in a certain build, the
detailed log of the failed testrun is stored on the slave's harddrive.
- all slaves normally have different setups, OS, package versions, gcc
versions etc. How can a committer resolve a build or test issue on a for her
probably unknown platform?
- current setup only tests getting code from a branch, would be nice to have
a builder which accepts release (candidate) packages to build and test those
on multiple slaves.
...
If anyone is interested in this buildbot configuration, please let me know.
I'm willing to spend the time to make this solution work for the Subversion
project. If it doesn't work in the end, atleast you get a better
understanding on the requirements of the Build & Test Farm.
regards,
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 21:39:51 2006