Sending email-ext messages to multiple recipients with friendly names

Question

The Problem

I am using Jenkins with the email-ext plugin to send HTML formatted emails to several recipient groups (distribution lists).

When configuring the list of recipients I have used the following formats:

"Development" <[email protected]>, "Software QA" <[email protected]>, "Project Management" <[email protected]>

OR without quotes …

Development <[email protected]>, Software QA <[email protected]>, Project Management <[email protected]>

Using these configurations Jenkins will only email the initially listed recipient.

Update

The behavior appears to be the same using only the email addresses, and no friendly names.

[email protected], [email protected], [email protected]

The Question

Is it possible to use these friendly names when sending mails from email-ext, or have I made an assumption which turns out inaccurate?

I couldn't find documentation indicating either way.

Environment

Jenkins: 2.57
Email-ext: 2.57.2

Bertilla

Answer 1

The Answer

As it turns out, some of the email addresses in the recipients list were also listed in the Jenkins/Email-Ext "Excluded Recipients" list.

This list is found under Manage Jenkins >> Configure System >> Extended E-mail Notification >> Excluded Recipients

There is no output from email-ext or the job's console to indicate this was the case, so it took time to track down.

I may open an enhancement request with the plugin owner to add some console output related to indicating whether excluded recipients are configured on the job.

Conclusion

Just to be clear: email-ext DOES support using friendly display names in the following formats:

Development <[email protected]> or "Development" <[email protected]>

Multiples are supported as the usual comma separated list.

Bertilla

Nice catch, more precise than my answer. +1 – Wigan

I'm using pipeline style for my job, is there a way to configure a recipients list ? – Pseudonymous

@ghassen I am unfamiliar with the pipelines options as we currently use Jenkins's UI for most or all configuration, as is the case here. However, you should be able to configure default recipients under Manage Jenkins >> Configure System. We just wanted more granular control of who received notifications. We have also switched to a chat ops integration (Slack, MS Teams, etc) vs sending emails. – Bertilla

On the day I'm writing this there's a bug that when your recipient list has only one e-mail it will slice this recipient based on the spaces. I've created pull request to fix thix: github.com/jenkinsci/email-ext-plugin/pull/395 but for now to workaround that you need to add , comma at the end of the e-mail address. Instead of Name Surname <[email protected]> write Name Surname <[email protected]>,. That would be nice to have it in accepted answer as I looked for it quite long. – Contrivance

Answer 2

I had to do this as well with friendly names to pick up some email lists from jenkins. Below is the syntax that worked for me. I declared primaryOwnerEmail and secondaryOwners [list of emails] and pulled them in the 'to:' line below.

    stage ("Notify Developers of Success"){
        env.ForEmailPlugin = env.WORKSPACE
        emailext attachmentsPattern: 'Checkmarx\\Reports\\*.pdf',
         to: "${primaryOwnerEmail},${secondaryOwners}",
         subject: "${env.JOB_NAME} - (${env.BUILD_NUMBER}) Finished Successfuly!",
         body: "Check console output at  ${env.BUILD_URL} to view the results"
    }

Because

Answer 3

If the JENKINS Email-ext plugin supported an extended email format, with a display name, that would be as

Project Management <[email protected]>

Yet, emailext/recipients/EmailRecipientUtilsTest.java does not show anywhere any display name, which is a strong case for its non support.

Wigan

Simply changing to the following provides the same result: [email protected], [email protected], [email protected] – Bertilla

@ChrisGiddings Then you can try and clone/compile the repo source, to see if at least the test class runs correctly. – Wigan

I think it's too idealistic to say, especially for OSS, that just because there's no test, there's no code that should've been tested :) Pipelines in Jenkins are an afterthought. – Blooper