after upgrading to Jenkins 1438 and Email-ext plugin 2.16 (and
updating everything else I use to the most current version) somehow
the mailing to the culprits who broke a build does not work anymore.
I even downgraded to email-ext 2.15 some minutes ago but the problem persists?!?
Where else could I look to find the cause?
What I have configured for the project:
Global recipient list: my email address
Still failing trigger: Recipient list: $PROJECT_DEFAULT_RECIPIENTS and
tick for "Send to recipients list" and tick for "Include culprits"
Changes and email adresses are retrieved via ClearCase and
ActiveDirectory/LDAP email plugin. At least for the changes the
translation from unix/CC short names into full names works, and I can
see from the logs that only a mail to me ist triggered:
13:01:50 Email was triggered for: Failure
13:01:50 Email was triggered for: Still Failing
13:01:50 Trigger Failure was overridden by another trigger and will
not send an email.
13:01:50 Sending email for trigger: Still Failing
13:01:50 Sending email to: Dirk.K...@xxx.com
13:01:50 Notifying upstream projects of job completion
13:01:50 Finished: FAILURE
This project is now failing for more than one hour and should have
about 10 people notified in the meantime. This has worked before, but
as failure does not occur that often I am not sure if the update could
have been the cause.
Thanks for any hints
Dirk
--
Never trust a short-haired guru
It was removed after upgrading to 2.16 because I saw errors when
mailing and the complaints on the mailing list. After downgrading to
2.15 it came back (because the field was empty?) and in this version,
it works (at least, does not give an error).
Shit, I removed it again, but the build is back to normal.:-/
BR
14:35:25 Email was triggered for: Failure
14:35:25 Email was triggered for: Still Failing
14:35:25 Trigger Failure was overridden by another trigger and will
not send an email.
14:35:25 Sending email for trigger: Still Failing
14:35:25 An attempt to send an e-mail to empty list of recipients, ignored.
14:35:25 Notifying upstream projects of job completion
14:35:25 Finished: FAILURE
My observation from 2.16 was, that $PROJECT_DEFAULT_RECIPIENTS was not
necessary any more because the "Recipient List" was automatically
filled from the "Global Recipient List"
Is it possible to get some more verbose logs?
Regards
Dirk
2011/11/10 Dirk Kuypers <kuyper...@googlemail.com>:
> No, in fact 2.16 should not have the default recipients in global config
> anymore. It does nothing. Somehow my repo got messed up before I issued a
> pull request and then when the merge occurred things went terribly wrong. I
> am working on fixing it using a clean fork/repo.
hm, ok. But now I am back to 2.15. And why does it not work anymore
with sending to culprits? Is there a possibility to get a hint via
logs?
can you post the end of the build log where the emails are being sent?
14:55:12 Time Elapsed 00:01:25.11
14:55:12 Build step 'Build a Visual Studio project or solution using
MSBuild.' marked build as failure
14:55:12 [WARNINGS] Skipping publisher since build result is FAILURE
14:55:12 Build does not meet criteria for workspace archiving -
result is not at least UNSTABLE.
14:55:12 Archiving artifacts
14:55:12 Recording fingerprints
14:55:54 Email was triggered for: Failure
14:55:54 Email was triggered for: Still Failing
14:55:54 Trigger Failure was overridden by another trigger and will
not send an email.
14:55:54 Sending email for trigger: Still Failing
14:55:55 Sending email to: Dirk.K...@xxx.com
14:55:55 Notifying upstream projects of job completion
14:55:55 Finished: FAILURE
BR
Dirk
2011/11/10 Slide <slide...@gmail.com>:
Not a lot of info there....I'll see what I can do.
In the first failing build I have the following changes pattern as
mentioned in the issue above.
Changes for Build #1759
[User A] Some text
[User B] Some text
[User A] Some text
[User A] Some text
[User A] Some text
[User A] Some text
[User C] Some text
[User A] Some text
We are using basic ClearCase and it does not support the concept of
commiting several files in one patch set. So it normally occurs in our
team that someone edited 10 files and checks those files in one file
per minute because the developer has to diff with the previous version
to generate a commit message. (That's not my style of work, but a lot
of people here are used to working like this for the last 10 years).
Dirk
2011/11/10 Slide <slide...@gmail.com>: