-
Bug
-
Resolution: Duplicate
-
Critical
-
occurs in email-ext plugin version 2.16
Version 2.16 of the plugin removes support for the PROJECT_DEFAULT_RECIPIENTS token, but leaves references to the token in the recipient lists for previously-configured build jobs. This causes build to attempt to send email to "$PROJECT_DEFAULT_RECIPIENTS" (literally), which of course fails. Delivery to legitimate addresses fails at the same time.
This is a breaking change, as it requires manually editing all existing jobs to remove the offending token reference. For installations with many jobs, this could be overwhelming. In general, it's not a good idea to remove functionality like this, therefore forcing your users to immediately reconfigure to use your alternate method. (i.e. the "ENV" token approach suggested in the commit comment.)
This change is also NOT listed in the version history for the plugin.
A typical failure stack trace follows.
Sending email to: real-address@mycompany.com $PROJECT_DEFAULT_RECIPIENTS
ERROR: Could not send email as a part of the post-build publishers.
javax.mail.SendFailedException: Invalid Addresses;
nested exception is:
com.sun.mail.smtp.SMTPAddressFailedException: 550 5.1.1 <$PROJECT_DEFAULT_RECIPIENTS>: Recipient address rejected: User unknown in local recipient table
at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:1196)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:584)
at javax.mail.Transport.send0(Transport.java:169)
at javax.mail.Transport.send(Transport.java:98)
at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:259)
at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243)
at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:692)
at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:667)
at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:645)
at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171)
at hudson.model.Run.run(Run.java:1448)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
- duplicates
-
-
- Resolved
-
[JENKINS-11913] Removal of PROJECT_DEFAULT_RECIPIENTS breaks existing jobs
rvaughn
added a comment - Hi ShuMei,
I honestly don't know - the commit comments for this change hinted that the ENV token could be used in place of this, but didn't give any details. It seems to me that it would be much more complicated that way - you will have to define the email recipient list in the environment of the build server, or use another plugin like EnvInject to set the build environment.
The workaround for me was simple but tedious - go through the "More Configuration" of every email trigger of every build job and manually delete the $PROJECT_DEFAULT_RECIPIENTS token if present. Not all of my build jobs had it, and I don't know why some did and some didn't.
If you were actually using the default recipient list, then it's a bit more complicated for you. I don't know how you will find out what the recipient list used to be for each job.
rvaughn
added a comment - Hi ShuMei,
I honestly don't know - the commit comments for this change hinted that the ENV token could be used in place of this, but didn't give any details. It seems to me that it would be much more complicated that way - you will have to define the email recipient list in the environment of the build server, or use another plugin like EnvInject to set the build environment.
The workaround for me was simple but tedious - go through the "More Configuration" of every email trigger of every build job and manually delete the $PROJECT_DEFAULT_RECIPIENTS token if present. Not all of my build jobs had it, and I don't know why some did and some didn't.
If you were actually using the default recipient list, then it's a bit more complicated for you. I don't know how you will find out what the recipient list used to be for each job. 
kutzi
added a comment - Changing functionality without implementing a migration path (and not even mentioning it on the Wiki page https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin) is a no-go => increasing priority to critical
kutzi
added a comment - Changing functionality without implementing a migration path (and not even mentioning it on the Wiki page https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin ) is a no-go => increasing priority to critical 
ShuMei Chang
added a comment - Thank you kutzi. I voted for critical, too. ShuMei Chang
added a comment - Thank you rvaughn. It is really tedious to go through hundreds of build jobs in our building .... I am kind of waiting and wishing that this problem would be fixed soon.
ShuMei Chang
added a comment - Thank you rvaughn. It is really tedious to go through hundreds of build jobs in our building .... I am kind of waiting and wishing that this problem would be fixed soon. rvaughn
added a comment - ShuMei,
You can revert to version 2.15 and you should be OK. Also see this thread: http://groups.google.com/group/jenkinsci-dev/browse_thread/thread/19255c17d06c5caf The last post contains a Groovy script that may be useful to you. If you're good at scripting, you may also be able to modify all of the config.xml files for your build jobs directly... though I would recommend doing that only with your Jenkins server shut down.
kutzi,
I agree - this is breaking change and should not have been released in this form. Apparently the dev responsible didn't intend for this change to be released yet, but a different maintainer did the release. That's poor release coordination in my book.
rvaughn
added a comment - ShuMei,
You can revert to version 2.15 and you should be OK. Also see this thread: http://groups.google.com/group/jenkinsci-dev/browse_thread/thread/19255c17d06c5caf The last post contains a Groovy script that may be useful to you. If you're good at scripting, you may also be able to modify all of the config.xml files for your build jobs directly... though I would recommend doing that only with your Jenkins server shut down.
kutzi,
I agree - this is breaking change and should not have been released in this form. Apparently the dev responsible didn't intend for this change to be released yet, but a different maintainer did the release. That's poor release coordination in my book. 
Axel Heider
added a comment - Any plan to fix this? There has been no activity for a month now.... Did you try to use the slicing-configuration plugin to bulk update all your jobs and remove the entry ?
(yes it is a workaround)
Just as an FYI, the release was put out without my knowledge, I was still working on making sure everything was fixed when the plugin was released by someone else. I apoligize for the problems and I am working on a full solution still. The ENV mechanism is easy, you can define environment variables in the global config, it does not take a special plugin or setup in the environment of the server. Just add an environment variable there with the list of emails, then you can use the ENV content token in the recipient field of any job.
Thank you rvaughn for reporting this bug. We took the Version 2.16 on Monday, and all the email notification broke immediately, not mentioned that the whole building was wondering what was going on with Jenkins. You have mentioned that we could take the "ENV" token approach to work around it before the bug resolved, would you mind to explain the steps you took for the "ENV" token approach? Thank you! Hopefully this issue will be resolved soon. Thanks again. Shu Mei