Re: Buildfarm feature request: some way to track/classify failures

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Buildfarm feature request: some way to track/classify failures
Date: 2007-03-16 19:35:23
Message-ID: 45FAF17B.7050906@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2007-03-16 19:38:45 Re: tsearch_core for inclusion
Previous Message Heikki Linnakangas 2007-03-16 19:28:08 Re: [PATCHES] Bitmapscan changes