-
Improvement
-
Resolution: Fixed
-
Critical
-
None
-
Platform: All, OS: Windows XP
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
- is duplicated by
-
-
- Closed
-
[JENKINS-279] Modular email notification
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.
Now at 27 votes (A reminder since there is no easy way to find issues with high
votes)
| Link |
New:
This issue is duplicated by |
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.
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. 
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?
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?
fixing platform