Details

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

      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

        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: