Thanks Jyoti,

Sorry for my late reply. I made a workaround for this and then I didn't 
check responses before vacation. The bug still exists in 17.7.

I'm aware of the confusion about "previous" which might be caused by out of 
order reruns, but that's not the cause for this.

Here are some log messages from my workaround code...

-- 
2017-08-17 11:39:33,939:INFO:root:Message with subject: Stage [
archive-post-recipe-feature-tests/937/defaultStage/1] passed 
-- 
2017-08-17 13:54:52,935:INFO:root:Message with subject: Stage [
archive-post-recipe-feature-tests/938/defaultStage/1] failed 
2017-08-17 13:54:52,935:WARNING:root:Got Event.FAILS instead of 
Event.BREAKS expected due to history. Changing! 
-- 
2017-08-17 16:41:14,408:INFO:root:Message with subject: Stage [
archive-post-recipe-feature-tests/939/defaultStage/1] passed 
2017-08-17 16:41:14,408:WARNING:root:Got Event.PASSES instead of 
Event.FIXED expected due to history. Changing! 

There are no intermediate reruns of this pipeline.

While it only seems to happen for particular pipelines, I can see that it 
sometimes works correct for this pipeline, so it's not consistent...:

2017-08-11 07:00:04,587:INFO:root:Message with subject: Stage [
archive-post-recipe-feature-tests/915/defaultStage/1] failed 
-- 
2017-08-11 09:17:50,343:INFO:root:Message with subject: Stage [
archive-post-recipe-feature-tests/916/defaultStage/1] is fixed 
-- 
2017-08-14 09:36:41,970:INFO:root:Message with subject: Stage [
archive-post-recipe-feature-tests/917/defaultStage/1] passed

Here it behaves as expected...

2017-07-27 03:30:54,430:INFO:root:Message with subject: Stage 
[archive-post-recipe-feature-tests/855/defaultStage/1] passed
--
2017-07-27 11:35:35,455:INFO:root:Message with subject: Stage 
[archive-post-recipe-feature-tests/856/defaultStage/1] is broken
--
2017-07-27 21:54:22,099:INFO:root:Message with subject: Stage 
[archive-post-recipe-feature-tests/857/defaultStage/1] failed

...and also in the other direction. For this particular pipeline I just see 
the two glitches for 937 and 938. Before that, it worked right.

When the problem first popped up, it happened repeatedly on the pipeline a 
developer had complained about, but never not on most other pipelines.

During the last 2.5 months, I've intercepted almost 25 000 emails, analyzed 
subject lines and emailed groups about broken or fixed pipelines 2005 
times, and 41 times I had to change a "passed" to "is fixed" or a "fails" 
to "is broken". 
It seems GoCD is 99.8% right on this, but the mistakes were noticed by a 
developer who asked why he didn't get those emails... 

I guess reruns could have caused some of the 41 glitches, but not any of 
the ones I checked.



Regarding implementation, I looked at the plugin APIs, but I decided that 
it would be easier to just let a single user subscribe to all events on all 
pipelines, and then handle this in a custom email proxy.

There were several reasons for that:

- The dependency on GoCD becomes trivial: Just SMTP, the email subject line 
and a single rest API: (pipeline groups).
- We can get a uniform notification mechanism defined in one place even if 
we scale up to more GoCD servers and if we want to include notifications 
from other systems than GoCD.
- I'm much quicker at getting something like this working in Python than in 
Java. It was just a little over 700 sloc + tests, including a plugin system 
for integrating with other software than GoCD, a little rules engine and 
the rules we need for this use case.

Den onsdag 17 maj 2017 kl. 17:15:06 UTC+2 skrev Jyoti Singh:
>
> Hi Magnus,
>
> Go server looks at the status of the previous run of the stage to decide 
> on the subject line for the notification email. It uses the rules that you 
> linked to ie. 
> https://docs.gocd.io/current/configuration/dev_notifications.html#events 
> to make the decision. 
>
> The behavior that you see though, i.e..  *Subject lines like "Stage 
> [xxx/16/build/1] failed" in my notification email, even though xxx/15 
> passed* would happen when an instance of that specific stage was rerun. 
>
> For example:
> StageFoo/15 passes, StageFoo/16 fails. The subject line of the email that 
> goes out would be "... is broken".
> However, if the sequence is StageFoo/15 passes, rerun StageFoo/11 and it 
> fails, trigger StageFoo/16, the email that comes out would have subject 
> line "... failed".
> It always compares with the previous run of the stage, not really the 
> previous counter, in this case the previous run would be counter 2 of 
> StageFoo/11. Does that help clarify the behavior that you see?
>
> Now, coming to the thing that you are trying to implement which is sending 
> the notifications to the team. Subscriptions through preferences are the 
> old way of getting notifications. You should be able to make use of the 
> email notifier plugin for this, you may checkout other notification plugins 
> on the website <https://www.gocd.io/plugins/>. If none of them suit your 
> needs, you could write one for yourself using the notifications plugin 
> endpoint 
> <https://plugin-api.gocd.io/current/notifications/#notification-plugins>.
>
> Hope that helps. 
>
> Cheers,
> Jyoti
>
>
> On Friday, 12 May 2017 21:21:25 UTC+5:30, Magnus Lyckå wrote:
>>
>> I'm running go-server 17.2.0. For some pipelines, I get subject lines 
>> like "Stage [xxx/16/build/1] failed" in my notification email, even though 
>> xxx/15 passed. For other pipelines, I get "is broken" as expected on a red 
>> build after a green.
>>
>> Since the teams want to get notifications for all the pipelines in their 
>> pipeline group etc without subscribing to notifications for each of them, I 
>> have a little mail server which subscribes to all events and then look at 
>> the email subject line and go/api/config/pipeline_groups to figure out who 
>> should get what. (See https://github.com/magnus-lycka/mail2alert ) This 
>> means that I don't know whether or not the go-server respects the rules in 
>> https://docs.gocd.io/17.5.0/configuration/dev_notifications.html#events 
>> wrt to sending email or not, I just know that the subject line on broken 
>> jobs for some piplines contains "failed" instead of "is broken"!, whether 
>> or not the previous run passed, while for other pipelines, this seems to 
>> work as expected.
>>
>> Any ideas?
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to