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

feature request for "all triggers" email-ext action

    XMLWordPrintable

Details

    Description

      I want to send email for every single run of my job. Rather than have to configure all triggers, a checkbox or "all" trigger config would be a nice convenience.

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          View 6 older comments
          slide_o_mix Alex Earl added a comment -

          Added Always trigger that is added to the list of triggers by default.

          slide_o_mix Alex Earl added a comment - Added Always trigger that is added to the list of triggers by default.
          danielbeck Daniel Beck added a comment -

          Alex: Why change the previous (2.32 or so) behavior to send upon failure (or unstable and worse?) by default? While we have quite a few projects we want to always be notified (success + failure), IMO the default should remain consistent to regular mailer, and not send for stable builds.

          danielbeck Daniel Beck added a comment - Alex: Why change the previous (2.32 or so) behavior to send upon failure (or unstable and worse?) by default? While we have quite a few projects we want to always be notified (success + failure), IMO the default should remain consistent to regular mailer, and not send for stable builds.
          slide_o_mix Alex Earl added a comment -

          Daniel: There were several people who assumed that if there were no triggers defined an email would ALWAYS be sent. I agreed with this as people were confused why they were getting no emails at all, they didn't know they had to setup a trigger to get emails for EVERYTHING.

          slide_o_mix Alex Earl added a comment - Daniel: There were several people who assumed that if there were no triggers defined an email would ALWAYS be sent. I agreed with this as people were confused why they were getting no emails at all, they didn't know they had to setup a trigger to get emails for EVERYTHING.
          danielbeck Daniel Beck added a comment -

          Alex: That assumption does make some sense. I wondered about triggers completely being missing by default compared to earlier versions of the plugin.

          However, I don't get where this leads to adding an 'Always' trigger by default. If it were 'Unstable' or 'Failure', it'd be just as obvious what the behavior is (and users still can customize the triggers to fit their needs, like removing the default trigger and adding the 'Always' trigger) – but it'd match what users might expect is the default coming from built-in Mailer. That's what I was referring to.

          Please re-consider this particular choice of the default list of email triggers. I'm sure it'll lead to a lot of unintended 'spam' from carelessly set up instances – Failures, you can argue are important, but successful build notifications? (FWIW it might actually make sense to make the default list of triggers added to new publisher instances configurable globally, similar to default email contents and content type)

          danielbeck Daniel Beck added a comment - Alex: That assumption does make some sense. I wondered about triggers completely being missing by default compared to earlier versions of the plugin. However, I don't get where this leads to adding an 'Always' trigger by default. If it were 'Unstable' or 'Failure', it'd be just as obvious what the behavior is (and users still can customize the triggers to fit their needs, like removing the default trigger and adding the 'Always' trigger) – but it'd match what users might expect is the default coming from built-in Mailer. That's what I was referring to. Please re-consider this particular choice of the default list of email triggers. I'm sure it'll lead to a lot of unintended 'spam' from carelessly set up instances – Failures, you can argue are important, but successful build notifications? (FWIW it might actually make sense to make the default list of triggers added to new publisher instances configurable globally, similar to default email contents and content type)
          slide_o_mix Alex Earl added a comment -

          Daniel: I'll consider it again before the next release. Even if the list of triggers were configurable, people wouldn't necessarily look there to set it up. I think the best option might be to revert to the older method of adding a failure trigger by default as you suggest.

          slide_o_mix Alex Earl added a comment - Daniel: I'll consider it again before the next release. Even if the list of triggers were configurable, people wouldn't necessarily look there to set it up. I think the best option might be to revert to the older method of adding a failure trigger by default as you suggest.

          People

            slide_o_mix Alex Earl
            raffenet Ken Raffenetti
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: