Hey folks,
I worked a fair bit on the build system automation this weekend. It's
not complete but it's better than it was:
http://linux.duke.edu/~skvidal/misc/buildsys/
it's two files now - archwelder.py and buildingsucks.py
archwelder keeps all the classes for building via mach for any given
arch, the xml-rpc communication class for the above and the xmlrpc
server side to run on the build hosts.
buildingsucks contains the 'tobuild' monitoring class and the queuer for
the builds. I've tested the xmlrpc communication for building using the
python shell as the 'client'. It looks like it works. I'm sure there are
some unfun bugs I've not noticed but it's an interesting place to work
from.
Structure:
buildingsucks sets up a monitor instance which checks out and parses
extras/common/tobuild from cvs.
Then it starts up a queuer instance for each package to be built. The
queuer checks the package out of cvs, makes the srpm and starts up jobs
for building. It uses the archwelder classes to do this. The queuer
doesn't care what archwelder instance it has or where the build is run
as long as it can access the same methods for any archwelder class.
The archwelder classes expect things to be in a known location as does
the queuer b/c it moves the files around.
packages are handled in stages:
active = being built/handled
needsign = built successfully but need to be signed
failed = did not succeed to build on any/all arches
success = succeeded and signed. - we actually don't care about this one
The code is not the most heinous thing in the world but there is a lot
of room for configuration to be extracted from the code (hah) and
improvement.
Known Bugs:
I'm having trouble getting the log output back across the xmlrpc
connection. I think it has something to do with some goofball characters
in the log output that the handler is retching at. That'll get sorted
soon enough.
-sv
