Peter Eisentraut wrote:
>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