On 11/16/2010 06:31 AM, Marius Dumitru Florea wrote: > Hi Vincent, > > On 11/16/2010 12:57 PM, Vincent Massol wrote: >> 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 > > Often a Hudson build includes multiple commits from different committers > so it's not always possible to know what commit broke the build. My use > case is this: multiple commits occur while all Hudson agents are busy > (build pending queue size > 0). By the time Hudson gets the chance to > (re)build a module, that module has been affected (directly or > indirectly) by multiple commits. Reporter lists all changes to the job and it's dependencies in their last build cycles so there is a list of revisions which might have caused the failure.
> >> - no false positives > >> - know who broke the build very visibly (with the commit that broke it) > > Same, I don't think this is always possible. > >> - console logs in the mail not to have to click on the link to get details > > +1 > >> - 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) > > +1 > >> - no duplicate mails. We receive one for the top level project and one for >> the each module right now > > Grouping the test results for each module is good IMO. Maybe not in > separate mails, a single mail would do just fine. I don't like the fact > that in Caleb's reports test failures from different modules are listed > together; in order to see the WYSIWYG selenium test failures I have > check the URLs. I will change the reports to include the job and module names with each test case but I'm concerned about sorting the test cases by module because I'd like to promote the idea that everyone should care about every test. > >> - no mails when build is successful; only when it fails > > One mail to notify that the build is back to normal is good IMO. I have a filter which directs this mail to the garbage. Adding a report which sends mail about any module which contains at least one test whose status is FIXED would be trivial but IMO unnecessary. Caleb > > Thanks, > Marius > >> >> 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 >> _______________________________________________ >> 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
