16 Nov
2010
16 Nov
'10
2:30 p.m.
On Nov 16, 2010, at 1:34 PM, Sergiu Dumitriu wrote:
On 11/16/2010 12:05 PM, Caleb James DeLisle wrote:
Well, unless we break things frequently and this happens for real... we do break stuff
frequently... so it's kind of normal we receive lots of emails :)
We can reduce them by:
- not sending the same email for false positives (we know for example that when we have an
X server issue it's not a real issue, no space left on device, etc We should be able
to list these messages and filter them out to send them in a different kind of mail,
grouped together for ex).
- not sending emails when the build is successful
- not sending several emails for the same problem
-Vincent
I'm amending this proposal to include what I
want to do further in the future.
My goal is to decrease the quantity of hudson mail while making it easier to use.
I would like to start by sending additional mail, one message per day with an aggregated
build
report and run a report which checks for new regressions and send mail every 10 minutes
or so when
there are regressions.
The second step is to solicit input about the usability of the new reports. I think
seeing reports
in action will make it easier to see what makes a report most useful. This will be
finished when we
are happy with the reports.
The third step is to remove the existing mail system. I will propose this step when I
think the new
reporting system is satisfactory.
WDYT?
Caleb
+1, it's been months since I haven't read hudson mails. I get hundreds
of mails from it each month, that's not normal. > On 11/15/2010 02:50 PM, Caleb James DeLisle
wrote:
>> I would like to get reports going out so that we can get a feel for the periodic
reports, and work
>> out bugs and make improvements in real time.
>>
>> I'm +1 to getting reports going.
>>
>>
>> A technical challenge is that unless one of the build agents has access to a mail
relay, it will not
>> be able to send mail. If this is a problem, it can be fixed by signing up with an
email service and
>> placing the password in a file on the filesystem of the agent which the job is
bound to. The file
>> can be loaded by the configuration script.
>>
>> Caleb