2006/11/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
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
Thanks,
Mikhail
geir
>
> Thanks,
> Mikhail
>
> 2006/11/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>>
>>
>> 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
>> >> IBM Java technology centre, UK.
>> >>
>> >
>>
