Thread: 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=spoonbill&dt=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=> ['me@foo.bar.com', 'him@baz.blurfl.com'}], > failures => 'bzzt@my.alarm.com' }, > > 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: <YYYY-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=<name>&br=<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
Andrew Dunstan <andrew@dunslane.net> 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
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> 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-2003:36:07dove | HEAD | 2005-06-17 01:10:00fantail | HEAD | 2004-12-06 23:04:43muskrat | HEAD | 2005-01-10 22:16:41osprey | HEAD | 2005-06-18 16:00:17osprey | REL8_0_STABLE | 2005-06-17 22:00:17penguin| REL8_0_STABLE | 2005-06-15 22:00:09 cheers andrew
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
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
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
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
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
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
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