Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-11913

Removal of PROJECT_DEFAULT_RECIPIENTS breaks existing jobs

    Details

    • 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

            Activity

            Hide
            shumei ShuMei Chang added a comment -

            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

            Show
            shumei ShuMei Chang added a comment - 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
            Hide
            rvaughn 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.

            Show
            rvaughn 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.
            Hide
            kutzi 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

            Show
            kutzi 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
            Hide
            shumei ShuMei Chang added a comment -

            Thank you kutzi. I voted for critical, too.

            Show
            shumei ShuMei Chang added a comment - Thank you kutzi. I voted for critical, too.
            Hide
            shumei 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.

            Show
            shumei 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.
            Hide
            rvaughn 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.

            Show
            rvaughn 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.
            Hide
            axelheider Axel Heider added a comment -

            Any plan to fix this? There has been no activity for a month now....

            Show
            axelheider Axel Heider added a comment - Any plan to fix this? There has been no activity for a month now....
            Hide
            aheritier Arnaud Héritier added a comment -

            Did you try to use the slicing-configuration plugin to bulk update all your jobs and remove the entry ?
            (yes it is a workaround)

            Show
            aheritier Arnaud Héritier added a comment - Did you try to use the slicing-configuration plugin to bulk update all your jobs and remove the entry ? (yes it is a workaround)
            Hide
            slide_o_mix Alex Earl added a comment -

            Duplicate of JENKINS-11683

            Show
            slide_o_mix Alex Earl added a comment - Duplicate of JENKINS-11683
            Hide
            slide_o_mix Alex Earl added a comment -

            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.

            Show
            slide_o_mix Alex Earl added a comment - 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.

              People

              • Assignee:
                slide_o_mix Alex Earl
                Reporter:
                rvaughn rvaughn
              • Votes:
                13 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: