Re: Buildfarm feature request: some way to track/classify failures
От | Andrew Dunstan |
---|---|
Тема | Re: Buildfarm feature request: some way to track/classify failures |
Дата | |
Msg-id | 45FAF17B.7050906@dunslane.net обсуждение исходный текст |
Ответ на | 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
("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>) |
Список | 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 по дате отправления: