public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrew Dunstan <[email protected]>
To: Postgresql Hackers <[email protected]>
Subject: Re: Build farm
Date: Thu, 20 Nov 2003 09:58:33 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

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

view thread (83+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Build farm
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox