[xwiki-devs] [Proposal] Jenkins emails configuration
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 * We send mail to the list when the build is fixed * 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) 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). Thanks -Vincent
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. 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
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
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
On Wed, Dec 19, 2012 at 4:21 PM, Vincent Massol <[email protected]> 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 * We send mail to the list when the build is fixed
+1
* 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)
+0.5
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).
+1 Thanks, Marius
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 12/19/2012 05:25 PM, Marius Dumitru Florea wrote:
On Wed, Dec 19, 2012 at 4:21 PM, Vincent Massol <[email protected]> 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 * We send mail to the list when the build is fixed
+1
* 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)
+0.5
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).
And it currently doesn't work, it's printed literally.
+1
-- Sergiu Dumitriu http://purl.org/net/sergiu
Vincent, just a hint. I am not receiving these mails so I cannot really say anything. However, continuous integration mails (and monitoring alarms) mails I've seen thus far always lack a feature that is really useful: threading: either using common subjects or In-Reply-To headers: a build breakage should be an email thread. paul Le 19 déc. 2012 à 15:21, Vincent Massol a écrit :
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 * We send mail to the list when the build is fixed * 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)
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).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Caleb James DeLisle -
Marius Dumitru Florea -
Paul Libbrecht -
Sergiu Dumitriu -
Vincent Massol