Merge of the Core EMailer and email-ext plugin
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.
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:
Issue list from email-ext: link
Issue list from the core emailer: link
For FIXED and freshly BROKEN builds I send standard emails with the core mailer to all developers
This is not possible with the email-ext plugin only, because when I have configured a build type
It would be cool if the design of the new mailer would respect this use case.
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.
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).
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
It would be useful to specify an administrator (or
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.
When building a maven build, use information from pom.xml to determine email recipients. For example:
Skip to end of metadata Go to start of metadata