Re: Buildfarm feature request: some way to track/classify failures - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Buildfarm feature request: some way to track/classify failures
Date
Msg-id 45FAF17B.7050906@dunslane.net
Whole thread Raw
In response to Buildfarm feature request: some way to track/classify failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Buildfarm feature request: some way to track/classify failures  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Buildfarm feature request: some way to track/classify failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Buildfarm feature request: some way to track/classify failures  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Tom Lane wrote:
> The current buildfarm webpages make it easy to see when a branch tip
> is seriously broken, but it's not very easy to investigate transient
> failures, such as a regression test race condition that only
> materializes once in awhile.  I would like to have a way of seeing
> just the failed build attempts across all machines running a given
> branch.  Ideally it would be possible to tag failures as to the cause
> (if known) and/or symptom pattern, and then be able to examine just
> the ones without known cause or having similar symptoms.
>
> I'm not sure how much of this is reasonable to try to do with webpages
> similar to what we've got.  But the data is all in a database AIUI,
> so another possibility is to do this work via SQL.  That'd require
> having the ability to pull the information from the buildfarm database
> so someone else could manipulate it.
>
> So I guess the first question is can you make the build data available,
> and the second is whether you're interested in building more flexible
> views or just want to let someone else do that.  Also, if anyone does
> make an effort to tag failures, it'd be good to somehow push that data
> back into the master database, so that we don't end up duplicating such
> work.
>
>             
>   

Well, the db is currently running around 13Gb, so that's not something 
to be exported lightly ;-)

If we upgraded from Postgres 8.0.x to 8.2.x we could make use of some 
features, like dynamic partitioning and copy from queries, that might 
make life easier (CP people: that's a hint :-) )

I don't want to fragment effort, but I also know CP don't want open 
access, for obvious reasons.

We can also look at a safe API that we could make available freely. I've 
already done this over SOAP (see example client at 
http://people.planetpostgresql.org/andrew/index.php?/archives/14-SOAP-server-for-Buildfarm-dashboard.html 
). Doing updates is a whole other matter, of course.

Lastly, note that some buildfarm enhancements are on the SOC project 
list. I have no idea if anyone will express any interest in that, of 
course. It's not very glamorous work.

cheers

andrew



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [PATCHES] Bitmapscan changes
Next
From: Robert Treat
Date:
Subject: Re: tsearch_core for inclusion