Sounds good (I like experiments ;)) but before going too far I'd like to see:
1) the needs we have regarding hudson mails.
For example, IMO we need:
- immediate notification after a commit that makes the build fail
- no false positives
- know who broke the build very visibly (with the commit that broke it)
- console logs in the mail not to have to click on the link to get details
- short and clear mail subjects (right now they're long and all look the same which
makes it hard to see which module is broken)
- no duplicate mails. We receive one for the top level project and one for the each module
right now
- no mails when build is successful; only when it fails
Do we agree about those needs? Any more?
2) how you report is addressing these needs in 1) and whether it's supposed to replace
the existing mails sent or come in addition to them. Also I'd like to know how
frequently it is sent? On each commit? On a time basis?
Thanks
-Vincent
On Nov 15, 2010, at 8: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