I have just seen the new way it is sending mail. I am able to glean information from the most recent messages. Thank you for this improvement.
+1 Thanks, Caleb On 12/19/2012 05:24 PM, Marius Dumitru Florea wrote: > On Wed, Dec 19, 2012 at 4:41 PM, Caleb James DeLisle > <[email protected]> wrote: >> Hi, >> >> On 12/19/2012 09:21 AM, Vincent Massol wrote: >>> Hi devs, >>> >>> I'm working on configuring jenkins email configuration for all jobs (I'm >>> scripting it). >>> >>> We need to agree on the mail sending strategy. >>> >>> Here's what I propose: >>> >>> * We send mail to the list when there's a build failure >> > >> How about only on regressions? We get a lot of failures and I just filter >> them all into /Hudson and clear it every few days. > > Vincent worked this week on filtering the build failures so that we > receive mails only for relevant failures, related to tests and not the > CI environment. See http://jira.xwiki.org/browse/XINFRA-72 . > > Thanks, > Marius > >> If it's easy to do, it would be really cool to get mail on regressions and >> on the first failure following a regression since it shows that it's not a >> flicker. >> >>> * We send mail to the list when the build is fixed >> >> I don't like this, I never look in /Hudson, I just goto the site if I want >> to get a picture of the current state. If other people read all of the mail >> coming from the ci then I suppose it serves a purpose but for me it's just >> load testing my mail client's sqlite3 database. >> >>> * We send a special mail with a different subject to committers/culprits >>> when there's a build failure (this is the "You broke the build! Fix it >>> now!" email that is currently sent by platform) >>> * We send a special mail with yet a different subject to >>> committers/culprits when there's a second build failure (this is the "Hurry >>> up! The build is still failing because of you! Stop whatever you're doing >>> and fix it!" email that is currently sent by platform) >> >> This is helpful since most of the regression mail is actually flickerspam. >> >>> >>> In addition I propose the following content: >>> >>> " >>> Check console output at $BUILD_URL to view the results. >>> >>> Failed tests: >>> ${FAILED_TESTS} >>> >>> Last build logs: >>> ${BUILD_LOG, ".*Finished at:.*", 100, 100, 0, true, null, false, null, true} >>> " >>> >>> (this last line means to include the 100 lines around the "Finished at" >>> message in the log). >> >> >> That's helpful, if it's easy to add a count of "persistently failing tests" >> to filter out flickers then that would be nice. >> >> Thanks, >> Caleb >> >>> >>> Thanks >>> -Vincent >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
