Re: [HACKERS] buildfarm notifications
On Sunday 19 June 2005 15:42, Josh Berkus wrote:
What are they testing and how? How often?
Regression tests on PostgreSQL, their own php tests on phpPgAdmin, and
standard JDBC test on pgJDBC.
Tests are based on when there have been submissions to CVS. They are doing
their best to do tests by patch.
I'd be interested in getting failure reports on phpPgAdmin... can you put me
in touch with someone wrt that ?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] buildfarm notifications
Robert, I'd be interested in getting failure reports on phpPgAdmin... can you put me in touch with someone wrt that ? I'll post to you KL as soon as it's publicly available. Currently you can only access the tests on Spike's intranet. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] buildfarm notifications
Andrew, If people don't monitor the buildfarm then it isn't serving its purpose of catching these things quickly. Related to that , Spikesource has started their automated tests (which currently include JDBC, php and phpPgAdmin as well as PostgreSQL). They have a web services interface; I was thinking of writing a widget which would e-mail notices of failures. Maybe I should send them to your list so that it's all one digest? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] buildfarm notifications
Josh Berkus wrote: Andrew, If people don't monitor the buildfarm then it isn't serving its purpose of catching these things quickly. Related to that , Spikesource has started their automated tests (which currently include JDBC, php and phpPgAdmin as well as PostgreSQL). They have a web services interface; I was thinking of writing a widget which would e-mail notices of failures. Maybe I should send them to your list so that it's all one digest? Er, who? What are they testing and how? How often? I am expecting that for the most part people will want the lists of state changes, rather than the lists of all builds or failures. Will Spikesource tests track state changes? BTW, these list are being set up only for announcements, so I would have to grant permission before any results started flowing. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] buildfarm notifications
Andrew, Er, who? www.spikesource.com. Also see my announcement to this list last Thursday. What are they testing and how? How often? Regression tests on PostgreSQL, their own php tests on phpPgAdmin, and standard JDBC test on pgJDBC. Tests are based on when there have been submissions to CVS. They are doing their best to do tests by patch. I am expecting that for the most part people will want the lists of state changes, rather than the lists of all builds or failures. Will Spikesource tests track state changes? They'd like to. CVS makes this kind of challenging.They'd be happy to have suggestions ... BTW, these list are being set up only for announcements, so I would have to grant permission before any results started flowing. Yep, that's why I'm mentioning it. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] buildfarm notifications
Josh Berkus wrote: I am expecting that for the most part people will want the lists of state changes, rather than the lists of all builds or failures. Will Spikesource tests track state changes? They'd like to. CVS makes this kind of challenging.They'd be happy to have suggestions ... In the buildfarm system, the state of each machine/branch is either OK or the stage in the buildfarm process that failed - we stop at the first such failure. Since all the data reported is stored in our db, finding the previous state is fairly simple - we just run this: select coalesce( (select distinct on (snapshot) stage from build_status where sysname = ? and branch = ? and snapshot ? order by snapshot desc limit 1), 'NEW') as prev_status plugging in the values from the current build. BTW, these list are being set up only for announcements, so I would have to grant permission before any results started flowing. Yep, that's why I'm mentioning it. send me details off-list. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] buildfarm notifications
Andrew Dunstan wrote: all: every build status received failures: every non-OK build status received all_changes: every time status changes green_changes: every time status changes to/from OK The digest mailing lists for these notifications are now alive. Corresponding subscription pages are at: http://pgfoundry.org/mailman/listinfo/pgbuildfarm-status-all http://pgfoundry.org/mailman/listinfo/pgbuildfarm-status-fail http://pgfoundry.org/mailman/listinfo/pgbuildfarm-status-chngs http://pgfoundry.org/mailman/listinfo/pgbuildfarm-status-green cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] buildfarm notifications
[from 2pc post mortem thread on -patches]
Stefan Kaltenbrunner wrote:
Looks suspicious, doesn't it. How long since you last tested on that
machine?
*argl* - it's not 2PC ...
the machine had some issues a week ago or so - but it looks like the
problem occured first here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbilldt=2005-06-15%2023:50:04
and in that changeset we have some timezone-patches ...
If people don't monitor the buildfarm then it isn't serving its purpose
of catching these things quickly. To aid that process I am currently
working on a notification enhancement for buildfarm which has long been
requested. Here's the description I sent to the buildfarm list (the
first few lines refer to how buildfarm members would have themselves
notified - non-buildfarm members can ignore):
Basically, it would work thus:
in your config file, put a setting like this:
mail_events = { all= ['[EMAIL PROTECTED]', '[EMAIL PROTECTED]'}],
failures = '[EMAIL PROTECTED]' },
The allowed event keys in this hash would be:
all: every build status received
failures: every non-OK build status received
all_changes: every time status changes
green_changes: every time status changes to/from OK
The corresponding values in the hash can be an arrayref of email
addresses, or a single scalar email address.
The notification sent by the server would look something like this:
Subject: PGBuildfarm member membername Branch branchname Status
[changed to] status
The PGBbuildfarm member membername had the following event on branch
branch:
Status: status (or Status Change from oldstatus to newstatus)
The snapshot timestamp for the build that triggered this notification
is: -MM-DD HH::mm::ss
The specs of this machine are:
OS: osname osversion
Arch: architecture
Comp: compiler compiler-version
For more information, see
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=namebr=branch
--
In addition, I am thinking of setting up mailing lists that digest all
these event sets for all members over a 24 hour period, and that
anyone can subscribe to.
The enhancement is almost done, and the whole thing will be complete
this weekend, I hope.
The mailing lists are being set up as digest-only, at least for the all
and failures lists - the state change lists should have much lower
volume, and I will probably make them digest optional.
comments welcome (buildfarm exists to help people on this list - if you
want something speak up).
cheers
andrew
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] buildfarm notifications
Andrew Dunstan [EMAIL PROTECTED] writes: comments welcome (buildfarm exists to help people on this list - if you want something speak up). There are a number of buildfarm machines that don't seem to have *ever* posted a successful run. In some cases this represents a genuine portability issue but in others it looks more like local misconfiguration. Can we do something to encourage people to fix these? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] buildfarm notifications
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: comments welcome (buildfarm exists to help people on this list - if you want something speak up). There are a number of buildfarm machines that don't seem to have *ever* posted a successful run. In some cases this represents a genuine portability issue but in others it looks more like local misconfiguration. Can we do something to encourage people to fix these? Yes. Thankyou for asking. Several of these have been inactive for quite a while, and I will mark those as retired after giving their owners due notice. Others I will chase up on a case by case basis. We've never been completely clean on anything before REL8_0_STABLE, so I'll be chasing the latest branches first. The obvious candidates are: sysname |branch | latest +---+- badger | HEAD | 2005-03-20 03:36:07 dove| HEAD | 2005-06-17 01:10:00 fantail | HEAD | 2004-12-06 23:04:43 muskrat | HEAD | 2005-01-10 22:16:41 osprey | HEAD | 2005-06-18 16:00:17 osprey | REL8_0_STABLE | 2005-06-17 22:00:17 penguin | REL8_0_STABLE | 2005-06-15 22:00:09 cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
