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

          raffenet Ken Raffenetti created issue -
          slide_o_mix Alex Earl added a comment -

          FYI, you CAN replicate this right now by adding a script trigger and just have the value of the script be "true" (no quotes). That should trigger for every status and send the emails. Not as convenient, but will meet your requirements before I can get around to implementing this.

          slide_o_mix Alex Earl added a comment - FYI, you CAN replicate this right now by adding a script trigger and just have the value of the script be "true" (no quotes). That should trigger for every status and send the emails. Not as convenient, but will meet your requirements before I can get around to implementing this.
          slide_o_mix Alex Earl added a comment -

          The difficulty with implementing this is that unless you setup any triggers, you won't be able to configure WHO to send the email to, unless you would just assume that only the people in the Recipient List should be sent emails.

          slide_o_mix Alex Earl added a comment - The difficulty with implementing this is that unless you setup any triggers, you won't be able to configure WHO to send the email to, unless you would just assume that only the people in the Recipient List should be sent emails.

          I'll backup and say that I was initially confused as to how to use this plugin. It was unclear that you needed to add triggers (which are hidden under the advanced settings pane), to give the plugin any functionality at all.

          In my case, I want an email to go to whomever pushed code that caused a build, no matter the result. What I was hoping was that I could use the $GIT_COMMITER envvar in the recipient list (this didn't work with the standard email notification option). Now that I know the workaround you suggested, I'm less concerned about seeing this feature implemented.

          raffenet Ken Raffenetti added a comment - I'll backup and say that I was initially confused as to how to use this plugin. It was unclear that you needed to add triggers (which are hidden under the advanced settings pane), to give the plugin any functionality at all. In my case, I want an email to go to whomever pushed code that caused a build, no matter the result. What I was hoping was that I could use the $GIT_COMMITER envvar in the recipient list (this didn't work with the standard email notification option). Now that I know the workaround you suggested, I'm less concerned about seeing this feature implemented.
          slide_o_mix Alex Earl added a comment -

          Thanks for the update, I'll still see about either given a warning or implementing something.

          slide_o_mix Alex Earl added a comment - Thanks for the update, I'll still see about either given a warning or implementing something.
          slide_o_mix Alex Earl added a comment -

          Created an Always trigger that will always send an email regardless of the status of the build. This trigger will be added by default when no triggers are defined yet.

          slide_o_mix Alex Earl added a comment - Created an Always trigger that will always send an email regardless of the status of the build. This trigger will be added by default when no triggers are defined yet.

          Code changed in jenkins
          User: Alex Earl
          Path:
          src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/config.groovy
          http://jenkins-ci.org/commit/email-ext-plugin/227d9b08bc85d5a4fa7c689c9acb4dddf2c44a75
          Log:
          Fix JENKINS-20013

          Added an Always trigger that is setup in the plugin by default. This
          trigger will ALWAYS trigger an email to recipients, requestor and
          culprits.

          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Alex Earl Path: src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/config.groovy http://jenkins-ci.org/commit/email-ext-plugin/227d9b08bc85d5a4fa7c689c9acb4dddf2c44a75 Log: Fix JENKINS-20013 Added an Always trigger that is setup in the plugin by default. This trigger will ALWAYS trigger an email to recipients, requestor and culprits.
          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.
          slide_o_mix Alex Earl made changes -
          Field Original Value New Value
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          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.
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 151535 ] JNJira + In-Review [ 193968 ]

          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: