Merge of the Core EMailer and email-ext plugin
No information for the plugin 'new-emailer' is available. It may have been removed from distribution.
Due to lack of progress in the new EMailer, the governance board decided on 2011/07/06 to take the email-ext-plugin as a starting point for the new EMailer instead of starting from scratch.
- bundle a stripped down (especially less configuration options) version of email-ext as the standard mailing plugin. Lets call it email2-core
- TODO: define which functionality should be included
- also check if email-ext lacks any of the functions of the current core mailer. If so, add them.
- define extension point(s) in email2-core, so optional plugins can add more options
- create a new optional plugin which adds (at least) all missing functionality from the current email-ext.
- deprecate the current core Mailer
- provide a smooth update path from the current core mailer and email-ext it to email2-core. Ideally fully automated
The new EMailer
At the moment there are two mailer components in Jenkins: the mailer from Jenkins core and email-ext.
These two components should be merged into a new plugin (no core any more) and updated to the new Jenkins APIs.
This Wiki page takes two responsibilities:
- collecting ideas and use cases which should be adressed by the new mailer (a kind of backlog)
- document the current release of the plugin
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.
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.
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).
- SuffixResolver: adds a suffix, e.g. "jhm" -> "email@example.com"
- 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 (firstname.lastname@example.org)
- 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)
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
Admin and Buildmaster email address
It would be useful to specify an administrator (or
"buildmaster") e-mail and the following options:
- 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...
- 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...
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.
Obtain email addresses from maven pom
When building a maven build, use information from pom.xml to determine email recipients. For example:
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.