Hi, On Tue, May 14, 2013 at 4:55 PM, Alex Parvulescu <[email protected]> wrote: > As previously stated (on Jukka's reference discussion) I think we need to > see the failures each time, otherwise we don't react accordingly.
Do we have evidence of cases where we haven't reacted accordingly after the first failure notification? Would those cases have been handled differently if more than one notification had been sent? If the answer is yes to both questions, then I agree that sending notifications for all build failures makes sense. Otherwise I'm not convinced. :-) > The proper way to handle a failure is to create a jira issue and mark the > test as ignored, this practice also keeps the noise down on the list. Agreed. This is orthogonal to whether one or more failure notifications get sent. > The spam filter situation is unfortunate, I've also been seeing huge > amounts of moderation emails caused by travis (basically each notification > hits the spam filter). > Is there a way to correct that on a larger scale, rather than approving > each one manually? I'm looking at some alternatives. For example we could set up a web hook gateway that turns Travis web hook notifications [1] to plain text emails with a non-variable sender address (the moderation trouble is caused by Travis switching to variable sender addresses some while ago). [1] http://about.travis-ci.org/docs/user/notifications/#Webhook-notification BR, Jukka Zitting
