Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Critical
-
Resolution: Duplicate
-
Component/s: email-ext-plugin
-
Environment:occurs in email-ext plugin version 2.16
-
Similar Issues:
Description
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)
Attachments
Issue Links
- duplicates
-
-
- Resolved
-
Activity
Duplicate of JENKINS-11683
Did you try to use the slicing-configuration plugin to bulk update all your jobs and remove the entry ?
(yes it is a workaround)
Any plan to fix this? There has been no activity for a month now.... 
Axel Heider
added a comment - Any plan to fix this? There has been no activity for a month now.... 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. 
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.