19 Dec
2012
19 Dec
'12
3:21 p.m.
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
19 Dec
19 Dec
3:41 p.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:24 p.m.
On Wed, Dec 19, 2012 at 4:41 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Dec
20 Dec
1:30 p.m.
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
<calebdelisle(a)lavabit.com> 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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
* 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
19 Dec
19 Dec
11:25 p.m.
On Wed, Dec 19, 2012 at 4:21 PM, Vincent Massol <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Dec
20 Dec
12:03 a.m.
On 12/19/2012 05:25 PM, Marius Dumitru Florea wrote:
On Wed, Dec 19, 2012 at 4:21 PM, Vincent Massol
<vincent(a)massol.net> wrote:
And it currently doesn't work, it's printed literally.
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
--
Sergiu Dumitriu
http://purl.org/net/sergiu
12:08 a.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4384
days inactive
4385
days old
6 comments
5 participants
participants (5)
-
Caleb James DeLisle -
Marius Dumitru Florea -
Paul Libbrecht -
Sergiu Dumitriu -
Vincent Massol