Andrew Dunstan writes:
Essentially what I have is something like this pseudocode:
cvs update
Be sure check past branches as well.
check if there really was an update and if not exit
OK.
configure; get config.log
Ideally, you'd try all possible option combinations for configure. Or at least enable everything.
I have had in mind from the start doing multiple configurations and multiple branches.
Right now I'm working only with everything/head, but will make provision for multiple sets of both.
How many branches back do you think should we go? Right now I'd be inclined only to do REL7_4_STABLE and HEAD as a default. Maybe we could set the default to be gettable from the web server so that as new releases come along build farm members using the default wouldn't need to make any changes.
However, everything would also be settable locally on each build farm member in an options file.
make 2>&1 | make-filter >makelog
make check 2>&1 | check-filter > checklog
You could also try out make distcheck. It tries out the complete build,
installation, uninstallation, regression test, and distribution building.
OK.
(TBD) send config status, make status, check status, logfiles
OK.
make distclean
When I played around with this, always copied the CVS tree to a new
directory and deleted that one at the end. That way, bugs in the clean
procedure (known to happen) don't trip up the whole process.
OK. We've also seen odd problems with "cvs update", I seem to recall, but I'd rather avoid having to fetch the entire tree for each run, to keep bandwidth use down. (I believe "cvs update" should be fairly reliable if there are no local changes, which would be true in this instance).
The send piece will probably be a perl script using LWP and talking to a
CGI script.
That will be the difficult part to organize, if it's supposed to be
distributed and autonomous.
sending the results won't be a huge problem - storing and displaying them nicely will be a bit more fun :-)
Upload of results would be over authenticated SSL to prevent spurious results being fed to us - all you would need to join the build farm would be a username/password from the buildfarm admin.
Thanks for your input
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
