The new EMailer

Merge of the Core EMailer and email-ext plugin

Plugin Information

No Information For This Plugin

The new EMailer

At the moment there are two mailer components in Hudson: the mailer from Hudson core and email-ext.

These two components should be merged into a new plugin (no core any more) and updated to the new Hudson APIs.

This Wiki page takes two responsibilities: 

  1. collecting ideas and use cases which should be adressed by the new mailer (a kind of backlog)
  2. document the current release of the plugin

Download

Plugin Version Hudson Version Download Changelog
0.1 1.3xx [Binary|^x.hpi|Binary] [Source|^x.zip|Source]
Initial release
0.1 1.3xx [Binary|^x.hpi|Binary] [Source|^x.zip|Source]
new feature 1

Documentation

todo

Ideas & Use Cases

Task List

0%

Task List

Quick Add
  1. handler

    Ability to send email at any interim point within the build process. For example, as a first step of the build or after a build step (triggering conidition may be success or failure)

    MEDIUM
    cpendleton
    Created:
    Nov 17, 2009
  2. handler

    Ability to send email when a user specified number of builds failed (e.g. user only wants to have an email when the build failed 3 (5, ..., n) times)

    MEDIUM
    mwoi
    Created:
    Sep 16, 2010
  3. handler

    Add ability to use SetEnv variable sfrom the setenv plugin

    MEDIUM
    tjurik
    Created:
    Dec 20, 2010
  4. handler

    Add the option of marking a email as urgent (setting the email priority)

    MEDIUM
    selwakumar
    Created:
    Dec 13, 2009
  5. handler

    For a multiconfiguration project, make it possible to send a single email in case of failure and/or success instead of an email for each of the configurations.

    MEDIUM
    jalexrod
    Created:
    Jun 04, 2010
  6. handler

    Give the user a possibility to maintain all its subscriptions/notfications at a single place (e.g. user settings page) instead of configuring it in each Job.

    MEDIUM
    selwakumar
    Created:
    May 03, 2010
  7. handler

    ability to add enviroment variables and parameterized build values to emails as tokens. eg: if a one of the choice vaules of a parameterized was "UAT" with the field name as ENV you can the following to the email on a successful build. "Built and released to the $ENV enviroment"

    MEDIUM
    md.csiitd@gmail.com
    Created:
    Oct 27, 2009
  8. handler

    allow for a nicely formatted and customizable HTML/CSS report of the build results

    MEDIUM
    md.csiitd@gmail.com
    Created:
    Apr 07, 2010
  9. handler

    the ability to include output from NCover, NDepend, other packages..

    MEDIUM
    md.csiitd@gmail.com
    Created:
    Aug 21, 2009
  10. handler

    the ability to support encrypted connection TSL on SMTP servers

    MEDIUM
    mmesa84
    Created:
    Feb 19, 2010
  11. handler

    completely working support for the ciManagement-Tag in the POM (see Issue http://issues.hudson-ci.org/browse/HUDSON-6421)

    HIGH
    svd
    Created:
    Jul 06, 2010

Issues

Issue list from email-ext: link

Issue list from the core emailer: link

Multiple configurations per job state

For FIXED and freshly BROKEN builds I send standard emails with the core mailer to all developers
and with the email-ext plugin I send additional e-mail with customized subjects and contents to the
committers of such builds.

This is not possible with the email-ext plugin only, because when I have configured a build type
once (like FIXED to be send to all developers), this type is not available anymore to be configured
again. Unfortunately with email-ext a build type can be configured only once.

It would be cool if the design of the new mailer would respect this use case.

Frank-Michael

Extension point: token provider

Provide an extension point for adding more mail tokens like $DEFAULT_SUBJECT or $BUILD_LOG.

The name of the token should be configured by the Hudson admin in the global configuration UI. The content is specified by the implementing class.

Jan

Extension point: mail resolver

Provide an extension point for adding mail resolvers.

A mail resolver is responsible for generating a valid email address from a name (usually the SCM username).

Possible resolvers:

  • SuffixResolver: adds a suffix, e.g. "jhm" -> "jhm@dev.java.net"
  • LdapResolver: asks the LDAP with "jhm" for an email adress
  • UserAccountResolver: store the email address in the users section (HUDSON_HOME/users/*)
  • PropertiesResolver: name-email pairs in a Java properties file (jhm=jhm@dev.java.net)
  • EmptyReslover: allow to e-mail without manipulating the name. This could be handled by allowing SuffixResolver to have empty suffix (which it currently don't). e.g. "jhm" -> "jhm" (Rickard vE)

Jan

Good configuration out of the box

The EMailer should have a configuration out of the box which works for 80% of the users (in sense of the overall 80-20 rule

  • show the last few lines of an unsuccessful build
  • show test results in the case of an unstable build

Jesse

Admin and Buildmaster email address

It would be useful to specify an administrator (or
"buildmaster") e-mail and the following options:

  1. option to send all e-mail sent by hudson also to this user (in CCplease! so that I can use mail filters); so that I can check for example if the content of e-mail is configured properly, if the e-mail has been sent to the right people for each job...
  2. option to send all e-mail related to configuration to this user ("notest results are found", cannot send e-mail to XXX user, ...), so that I can promptly be informed if a configuration of a job is not correct (without waiting for a developer to tell me that there is a problem!) or if a global option is not valid and so on...

Marco Ambu

Send email after manually triggering build

Scenario: a user is logged in (authorization is turned on), and triggers a build manually (by "Build Now").

It should be possible to configure that an email is sent to the triggering user (on success, on failure, etc.) analogously to the case the user triggered a build by checking in something to the SCM.

Stefan

Obtain email addresses from maven pom

When building a maven build, use information from pom.xml to determine email recipients.  For example:
<developers>
<developer>
<id>chonton</id>
<name>Chas</name>
<email>chas@nowhere.org</email>
</developer>
</developers>
Additionally, if only the commiter should be notified, the developer <id> could be used to match the commiter's scm identity to his developer profile.

Labels:

plugin-notifier plugin-notifier Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Sep 14, 2010

    Srinath Balaraman says:

    I think we should also add a requirement for the ability to add attachments to t...

    I think we should also add a requirement for the ability to add attachments to the email.

  2. Jan 12, 2011

    Hetal Shah says:

    The atttachement requirement which was posted earlier, is it available in the cu...

    The atttachement requirement which was posted earlier, is it available in the current version of plugin.
    If yes then can you please tell me that how to configure it and no then can you please tell me when this feature will be available ?

    Thanks in advance !

    ~Hetal