harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [build-test] CI behavior for email ( was Re: [build-test] Should we setup a separate mail list for "alerts"?)
Date Tue, 28 Nov 2006 15:31:54 GMT


Mikhail Loenko wrote:
> 2006/11/28, Geir Magnusson Jr. <geir@pobox.com>:
>>
>>
>> Mikhail Loenko wrote:
>> > What if I just returned from trip/vacation/something else
>> >
>> > How can I know if some regular check is broken or not?
>>
>> Meaning that you unsubbed mail and therefore have no clue about current
>> state?  That is a corner case IMO (why are you unsubbing? :)
>>
>> The solution is the "dashboard".  When we first started talking about
>> this, an important piece is the as-yet-done "dashboard" - a single
>> webpage somewhere where the status of every configuration under CI is
>> shown (green/red or something).
>>
>> The dashboard system ("harmonytest.org"?) would get a mail feed of the
>> alerts - yet another good reason to have it's own list - and update on
>> each mail it got.
>>
>> >
>> > We probably need a wiki table with all possible regular runs and key 
>> words
>> > for them, so that I can find mails in my box containing that key word.
>> > Makes sense?
>>
>> Yes.  I do highly reccommend filters though...
> 
> Filters are good to separate alerts from commits, but what's about
> when we will be watching 10 applications on 6 platforms? I'd like to
> be able to easily find the status
> of each specific configuration
> 

Agreed.  I posted a "straw man" at the bottom of :

   http://wiki.apache.org/harmony/Automated_Testing

with the expectation that someone will rip it apart and do something 
better :)

geir

> Thanks,
> Mikhail
> 
>>
>> geir
>>
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/11/28, Geir Magnusson Jr. <geir@pobox.com>:
>> >>
>> >>
>> >> Vladimir Ivanov wrote:
>> >> > Could we just exclude test while it is under investigation?
>> >> > In this case we will see only one notification for each failure.
>> >> >
>> >>
>> >> That is somewhat orthogonal, because the CI system shouldn't care what
>> >> we humans are doing - the "one notification" is automatic, based on 
>> "las
>> >> state" and "current state".
>> >>
>> >> My thought was that CI would send a "BUILD FAILED" email when the 
>> build
>> >> broke on some platform/config, and wouldn't ever send another mail 
>> under
>> >> the build-test cycle was successful, and then it would send "BUILD
>> >> FIXED".
>> >>
>> >> Only then could it ever send a "BUILD FAILED" again.
>> >>
>> >> My problem is that CI is repeatedly sending email - it shouldn't until
>> >> things a healthy.
>> >>
>> >> For any given problem, we humans could choose to
>> >>
>> >> a) exclude the test while someone works on it.  That would then result
>> >> in a SVN change that would trigger the cycle again, and if successful
>> >> send a "BUILD FIXED".
>> >>
>> >> b) fix the code - resulting in the above cycle and "BUILD FIXED" email
>> >> if successful
>> >>
>> >> c) something else
>> >>
>> >> but it doesn't matter - CI should just run based on 'last state',
>> >> changes in SVN, succeess/failure of build/test run, and with that info
>> >> and last state :
>> >>
>> >> 1)  send a "BUILD FIXED" - if last state was failed and the last
>> >> build/test run was successful
>> >>
>> >> 2) send a "BUILD FAILED" - if last state was successful and build/test
>> >> run failed
>> >>
>> >> 3) send nothing - if last state was failed and build/test run failed
>> >>
>> >> 3) send nothing - if last state was successful and build/test run was
>> >> successful
>> >>
>> >>
>> >> geir
>> >>
>> >>
>> >> > Thanks, Valdimir
>> >> >
>> >> >
>> >> > On 11/28/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> >> >>
>> >> >> Geir Magnusson Jr. wrote:
>> >> >> > Each of us can use filters to sort them, but it seems like
it
>> >> wouldn't
>> >> >> > be a bad idea having a separate list for this kind of thing.
>> >> comments?
>> >> >>
>> >> >> I'm happy enough for them to be on the commit list, but as you

>> wrote
>> >> >> elsewhere we need to stop getting repeated messages for the same
>> >> failed
>> >> >> state (these are being worked on).
>> >> >>
>> >> >> Regards,
>> >> >> Tim
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Tim Ellison (t.p.ellison@gmail.com)
>> >> >> IBM Java technology centre, UK.
>> >> >>
>> >> >
>> >>
>>

Mime
View raw message