Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: mailer-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: Windows XP
    • Similar Issues:
      Show 5 results

      Description

      We like spam from our build tool.

      We like getting a nice email telling us that everything is OK.

      Hudson should have an options to send emails:
      1. To a specific list of people for failing builds.
      2. To a different list of people for unstable builds.
      3. To a third list of people for each stable normal build.

      Or else add multiple email addresses sets and have tick boxes for each set
      specifying the address email preferences from:
      1. Every broken build
      2. First broken build since normal or unstable
      3. Every unstable build
      4. First unstable build since broken or normal
      5. Every normal build
      6. First normal build since broken or unstable

        Attachments

          Issue Links

            Activity

            Hide
            stephenconnolly stephenconnolly added a comment -

            fixing platform

            Show
            stephenconnolly stephenconnolly added a comment - fixing platform
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Bumping up the priority to reflect user interest.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Bumping up the priority to reflect user interest.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            It would be desirable for various facets of the e-mail notification to be
            separate out, and each made extensible.

            For example, there's "when" configuration, which determines which build should
            trigger an e-mail notification. There could be "what" configuration, which
            determines the e-mail contents. There's also "who", which determines who will
            receive e-mails. Those aspects are orthogonal.

            Making them extensible allows plugins to contribute somewhat unusual
            implementation, thereby allowing us to keep the core options relatively simple.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - It would be desirable for various facets of the e-mail notification to be separate out, and each made extensible. For example, there's "when" configuration, which determines which build should trigger an e-mail notification. There could be "what" configuration, which determines the e-mail contents. There's also "who", which determines who will receive e-mails. Those aspects are orthogonal. Making them extensible allows plugins to contribute somewhat unusual implementation, thereby allowing us to keep the core options relatively simple.
            Hide
            stephenconnolly stephenconnolly added a comment -

            Now at 27 votes (A reminder since there is no easy way to find issues with high
            votes)

            Show
            stephenconnolly stephenconnolly added a comment - Now at 27 votes (A reminder since there is no easy way to find issues with high votes)
            Hide
            jglick Jesse Glick added a comment -
                • Issue 817 has been marked as a duplicate of this issue. ***
            Show
            jglick Jesse Glick added a comment - Issue 817 has been marked as a duplicate of this issue. ***
            Hide
            jbq jbq added a comment -

            Better issue title

            Show
            jbq jbq added a comment - Better issue title
            Hide
            kdsweeney kdsweeney added a comment -

            I'm working on making the triggers and content extensible, based on the
            email-ext plugin. My ideas so far are:

            Trigger - basically implement a trigger abstract class (very similar to writing
            a plugin for core hudson) and implement a method that can determine whether or
            not conditions are right for triggering an email.

            Content - You can define a string to be replaced by actual content when the
            email is sent. For example, $HUDSON_URL will be replaced by the actual url to
            the Hudson instance. This will also be similar to defining a plugin. You will
            need to implement a method that returns the symbol to be replaced, and also a
            method that returns the actual content to replace the symbol.

            As far as recipients, I think I will leave it as it is. Check out the email-ext
            plugin to see how this works currently.

            Show
            kdsweeney kdsweeney added a comment - I'm working on making the triggers and content extensible, based on the email-ext plugin. My ideas so far are: Trigger - basically implement a trigger abstract class (very similar to writing a plugin for core hudson) and implement a method that can determine whether or not conditions are right for triggering an email. Content - You can define a string to be replaced by actual content when the email is sent. For example, $HUDSON_URL will be replaced by the actual url to the Hudson instance. This will also be similar to defining a plugin. You will need to implement a method that returns the symbol to be replaced, and also a method that returns the actual content to replace the symbol. As far as recipients, I think I will leave it as it is. Check out the email-ext plugin to see how this works currently.
            Hide
            dfabulich dfabulich added a comment -

            This issue has 115 votes, making it by far the most popular issue in Hudson.

            At the same time, it seems like this issue has been mostly handled by the
            Email-Ext plugin. Will Hudson fold this plugin into the core of Hudson? If
            not, maybe this issue should be marked WONTFIX.

            FWIW, I think that the Email-Ext plugin is pretty complicated; it probably
            doesn't need to get rolled into Hudson, and could significantly complicate
            Hudson's easy-to-use UI by adding in this feature.

            However, this issue was originally described as "Email on successful normal
            build." I think it would be great to just add in a checkbox to handle that
            case. That wouldn't let you configure arbitrary e-mail lists on various build
            triggers, but it would let you get an e-mail when the build passed. Maybe that
            should be a separate issue?

            Show
            dfabulich dfabulich added a comment - This issue has 115 votes, making it by far the most popular issue in Hudson. At the same time, it seems like this issue has been mostly handled by the Email-Ext plugin. Will Hudson fold this plugin into the core of Hudson? If not, maybe this issue should be marked WONTFIX. FWIW, I think that the Email-Ext plugin is pretty complicated; it probably doesn't need to get rolled into Hudson, and could significantly complicate Hudson's easy-to-use UI by adding in this feature. However, this issue was originally described as "Email on successful normal build." I think it would be great to just add in a checkbox to handle that case. That wouldn't let you configure arbitrary e-mail lists on various build triggers, but it would let you get an e-mail when the build passed. Maybe that should be a separate issue?
            Hide
            dfabulich dfabulich added a comment -

            adding myself to cc

            Show
            dfabulich dfabulich added a comment - adding myself to cc
            Hide
            dmulter dmulter added a comment -

            I for one am just looking for email notification on all builds whether they pass or fail.

            Show
            dmulter dmulter added a comment - I for one am just looking for email notification on all builds whether they pass or fail.
            Hide
            mdonohue mdonohue added a comment -

            For those who just want an email for every successful build, see issue 2651.
            This is already implemented in email-ext.

            Show
            mdonohue mdonohue added a comment - For those who just want an email for every successful build, see issue 2651. This is already implemented in email-ext.
            Hide
            kenliu kenliu added a comment -

            add self to cc

            Show
            kenliu kenliu added a comment - add self to cc
            Hide
            slide_o_mix Alex Earl added a comment -

            Isn't this issue moot with email-ext? It seems to provide everything that people are looking for in this issue.

            Show
            slide_o_mix Alex Earl added a comment - Isn't this issue moot with email-ext? It seems to provide everything that people are looking for in this issue.
            Hide
            mkruer Matthew Kruer added a comment -

            I think that the upcoming plugin emailext-template plugin https://issues.jenkins-ci.org/browse/JENKINS/component/18764 more or less will solve this completely. Define a e-mail template and then assign the template to the job. Once assigned you can modify the e-mail criteria in one location.
            Just my 2 cents

            Show
            mkruer Matthew Kruer added a comment - I think that the upcoming plugin emailext-template plugin https://issues.jenkins-ci.org/browse/JENKINS/component/18764 more or less will solve this completely. Define a e-mail template and then assign the template to the job. Once assigned you can modify the e-mail criteria in one location. Just my 2 cents
            Hide
            integer Kanstantsin Shautsou added a comment -

            email-ext plugin is solving this issue.

            Show
            integer Kanstantsin Shautsou added a comment - email-ext plugin is solving this issue.

              People

              • Assignee:
                Unassigned
                Reporter:
                stephenconnolly stephenconnolly
              • Votes:
                56 Vote for this issue
                Watchers:
                22 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: