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...
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.
>>
>
