X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 0F635D1B4F6 for ; Thu, 20 Nov 2003 14:59:00 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 44995-03 for ; Thu, 20 Nov 2003 10:58:32 -0400 (AST) Received: from trolak.mydnsbox2.com (ns1.mydnsbox2.com [207.44.142.118]) by svr1.postgresql.org (Postfix) with ESMTP id E0778D1D606 for ; Thu, 20 Nov 2003 10:58:27 -0400 (AST) Received: from dunslane.net (x.ncshp.org [199.90.235.43]) (authenticated (0 bits)) by trolak.mydnsbox2.com (8.11.6/8.11.6) with ESMTP id hAKFtQa30287 for ; Thu, 20 Nov 2003 09:55:26 -0600 Message-ID: <3FBCD699.7050502@dunslane.net> Date: Thu, 20 Nov 2003 09:58:33 -0500 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Postgresql Hackers Subject: Re: Build farm References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/1119 X-Sequence-Number: 47407 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