Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about the default email notification about how to use email-ext to replace Jenkins. Many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

1 brief introduction

As we all know, Jenkins provides an email notification by default, which can send mail after build failure, build instability, and so on. But it has many limitations, such as its email notification can not provide detailed email content, unable to define the format of sending mail, unable to define flexible email receiving configuration, and so on. In this case, we found Jenkins Email Extension Plugin. The plugin allows you to customize all aspects of email notifications, such as who you send email to, what content to send, and so on.

2 configuration

It mainly consists of two parts: global configuration and project configuration.

2.1 Global configuration

Of course, before you can apply the email-ext plug-in to a project, you must do some global configuration. Now jump to Jenkins's "system Settings" page, as shown below: find the snippet titled "Extended E-mail Notification" and you can configure some global email-ext properties. These properties must match the settings of your SMTP mail server. This section can not only be configured as a mirror of Jenkins's original mail notifications (although many of the configurations are the same, but this is a different extension point), but also adds some additional features. Items named Default Subject and Default Content in the input box allow you to configure messages within the global level

Rong. By doing so, you can make better and simpler configurations for all projects according to your needs. As shown in the following picture.

Release my configuration:

Default Subject: build Notification: $PROJECT_NAME-Build # $BUILD_NUMBER-$BUILD_STATUS!

Default Content:

This email is sent automatically by the program, please do not reply!

Project name: $PROJECT_NAME

Build number: $BUILD_NUMBER

Svn version number: ${SVN_REVISION}

Build status: $BUILD_STATUS

Trigger reason: ${CAUSE}

Build log address: ${BUILD_URL} console

Build address: $BUILD_URL

Changeset: ${JELLY_SCRIPT,template= "html"}

Let's explain some of the common properties.

2.1.1 detailed explanation of global attributes

1. Override Global Settings: if not selected, the plug-in will use the default E-mail Notification notification option. Instead, you can override it by specifying a setting that is different from the default option.

2. Default Content Type: specify the type of email content to be sent after the build, including Text and HTML.

3. Use List-ID Email Header: set a List-ID header for all emails so that you can use filtering on the email client. It can also prevent most automatic responses from the sender (such as leaving the office, taking a vacation, etc.). You can use any customary name or ID number, but they must conform to one of the following formats (the real ID must be included in the tag):

Build Notifications

"Build Notifications"

For a more detailed description of List-ID, see RFC-2919.

4. Add 'Precedence: bulk' Email Header: set priority. For more information, please see RFC-3834.

5. Default Recipients: customize the default email recipient list. If it is not overridden by the project configuration, the plug-in uses this list. You can use the $DEFAULT_RECIPIENTS parameter in the project configuration to include this default list, as well as add new addresses at the project level. Add CC: cc: email address for example, CC:someone@somewhere.com

6. ReplyTo List: reply list, A comma separated list of e-mail addresses to use in the ReplyTo header ofthe email. This value will be available as $DEFAULT_REPLYTO in the project configuration.

7. Emergency reroute: if this field is not blank, all emails will be sent separately to that address (or address list).

8. Excluded Committers: to prevent mail from being considered spam by the mail system, the mailing list should not have an extended account name

(e.g. @ domain.com), separated by commas

9. Default Subject: the default subject name for custom mail notifications. This option replaces some parameters in the subject field of the message so that you can use the

The specified output information is included in the build.

10. Maximum Attachment Size: the maximum attachment size of the message.

11. Default Content: the default content body for custom mail notifications. This option replaces some parameters in the contents of the message so that you can build the

Contains the specified output information.

12. Default Pre-send Script: default script executed before sending (Note: grooy script, which I saw in an article, not necessarily accurate).

13. Enable Debug Mode: enables the debug mode of the plug-in. This will add additional log output, build logs, and Jenkins logs. Debugging

It is useful, but it cannot be used in production.

14. Enable Security: when enabled, the ability to send scripts is disabled and goes directly to the Jenkins instance. If the user attempts to access the Jenkins management pair

Like an instance, a security exception will be thrown.

15. Content Token Reference: variables that can be used in the message, all variables are optional. For more information, please see the global mail variable.

Chapter.

2.1.2 Global mail variables

Ps: I feel a little dizzy when I look at it. It's better compared to the Jenkins page.

The email-ext plug-in allows you to use variables to dynamically insert data into the subject and content body of the message. A variable is a string that starts with $(dollar sign) and ends with a space. When a message is triggered, all variables in the subject and content body fields are replaced dynamically with real values. Similarly, the "value" in the variable can contain other variables and will be replaced with the real content. For example, the default theme and content of the project configuration page corresponds to the DEFAULT_SUBJECT and DEFAULT_CONTENT of the global configuration page, respectively, so it automatically uses the global configuration. Similarly, the Subject and Content in the trigger correspond to the DEFAULT_SUBJECT and Content of the project configuration page, respectively.

DEFAULT_CONTENT, so it also automatically uses the configuration of the project. Because the "values" in variables can contain other variables, you can quickly create different pointcuts for variables: global level (all projects), exclusive level (single project), trigger level (build result). If you want to view all available variables, you can click the question mark of Content Token Reference on the configuration page for more information. All variables are optional, and each variable can be represented as follows, using name= "value" for string types and name=value for Boolean and numeric types. If there are no variables in the {and} tags, they will not be parsed. Example: $TOKEN,$ {TOKEN}, ${TOKEN,count=100}, ${ENV,var= "PATH"}

Tip: use English commas to separate the parameters of variables. Let me explain the commonly used properties.

${FILE,path= "PATH"} includes the content of the specified file (path) relative to the workspace root directory. Path file path, note: it is the relative path of the workspace directory.

${BUILD_NUMBER} displays the number of the current build.

${JOB_DESCRIPTION} displays the project description.

${SVN_REVISION} displays the svn version number. The SVN_REVISION_n version of the Subversion plug-in export is also supported.

${CAUSE} shows who and through what channels triggered the build.

${CHANGES}-shows the changes since the last build.

If showPaths is true, the address of the submitted modification is displayed. Default false.

If showDependencies is true, it shows the project build dependency. Default is false

Format iterates through the submission information, a string containing% X, where% a represents the author,% d represents the date,% m represents the message,% p indicates the path, and% r represents the version. Note that not all version systems support% d and% r. If you specify showPaths, it will be ignored. The default is "[% a]% m\ n".

PathFormat A string containing "% p" to indicate how to print the path.

${BUILD_ID} displays the ID generated by the current build.

${PROJECT_NAME} displays the full name of the project. (see AbstractProject.getFullDisplayName)

${PROJECT_DISPLAY_NAME} displays the display name of the project. (see AbstractProject.getDisplayName)

${SCRIPT} generates custom message content from a script. Custom scripts should be placed at "$JENKINS_HOME/email-templates". The $JENKINS_HOME/email-templatesdirectory directory is searched by default when using custom scripts. Other directories will not be searched.

When script is used, only the last value is used by the script (script and template cannot be used at the same time).

Template regular simpletemplateengine format template.

${JENKINS_URL} displays the url address of the Jenkins server (you can change it on the system configuration page).

${BUILD_LOG_MULTILINE_REGEX} matches by regular expression and displays the build log.

Regex java.util.regex.Pattern generates a build log that matches regular expressions. No default value, but empty.

The maximum number of maxMatches matches. If 0, all will be matched. The default is 0.

If showTruncatedLines is true, it contains [... truncated # lines...] All right. The default is true.

If substText is not empty, insert this part of the text (instead of the whole line) into the message. The default is empty.

If escapeHtml is true, format HTML. The default is false.

If matchedSegmentHtmlStyle is not empty, output HTML. The number of matching lines will be changed to html escaped matched line format. The default is empty.

${BUILD_LOG} displays the final build log.

The maximum number of rows displayed in the maxLines log, which defaults to 250lines.

If escapeHtml is true, format HTML. Default false.

${PROJECT_URL} displays the URL address of the project.

${BUILD_STATUS}-displays the status of the current build (failure, success, etc.)

${BUILD_URL}-displays the currently built URL address.

${CHANGES_SINCE_LAST_SUCCESS}-shows the changes since the last successful build.

Reverse marks the recent build at the top. Default false.

Format iterates through the build information, a string containing% X, where% c is all changes and% n is the build number. Default "Changes for Build # nn%cn"

ShowPaths,changesFormat,pathFormat defines showPaths, format, and pathFormat parameters such as ${CHANGES}, respectively.

${CHANGES_SINCE_LAST_UNSTABLE}-the display shows the changes since the last unstable or successful build.

Reverse marks the recent build at the top. Default false.

Format iterates through the build information, a string containing% X, where% c is all changes and% n is the build number. Default "Changes for Build # nn%cn"

ShowPaths,changesFormat,pathFormat defines showPaths, format, and pathFormat parameters such as ${CHANGES}, respectively.

${ENV}-displays an environment variable.

Var- displays the name of the environment variable. If empty, all is displayed, and the default is empty.

${FAILED_TESTS}-if there are failed tests, display these failed unit test information.

${JENKINS_URL}-displays the address of the Jenkins server. You can change it on the system configuration page.

${HUDSON_URL}-not recommended, please use $JENKINS_URL

${PROJECT_URL}-displays the URL of the project.

${SVN_REVISION}-displays the version number of the SVN.

${JELLY_SCRIPT}-customize the message content from a Jelly script template. There are two templates to configure: HTML and TEXT. You can do it in the

Replace it with customization under $JENKINS_HOME/email-templates. When using autosense templates, the name of the "template" parameter does not contain ".jelly".

Template template name, default "html".

${TEST_COUNTS}-displays the number of tests.

Var- defaults to "total".

Total-number of all tests.

Fail-number of failed tests.

Skip-number of skipped tests.

2.2 Project configuration

To use the email-ext plug-in in a project, you must first activate it on the project configuration page. Check the "Editable Email Notification" tag in the post-build operation-- "Add Post-build Actions" option.

2.2.1 basic configuration of the project

When the plug-in is activated, you can edit the following fields (list only commonly used fields):

Project Recipient List: this is a list of email addresses of recipient messages separated by commas (or spaces). Allows you to specify a separate list for each message. Ps: if you want to add the recipient to the default recipient: $DEFAULT_RECIPIENTS

Default Subject: allows you to configure the subject of this project message.

Default Content: it does the same thing as Default Subject, but replaces the content of the message.

Attach Build Log: attachment build log.

Compress Build Log before sending: compress the generated log before sending (zip format).

2.2.1.1 Project Advanced configuration

To view the advanced configuration of the plug-in, click the Advanced button. This option allows you to specify recipients for various types of mail triggers. By default, there are no configured triggers, so messages are not sent by default. To add more triggers, select the type in the drop-down list next to "Add a Trigger", which will be added to the list above the control. Once you add a trigger, you can make some choices about it. If you click "?" next to a trigger Number, which will tell you under what conditions email will be triggered. As shown in the following picture.

Send to Recipient List: if checked, the mail will be sent to all email addresses in "Project Recipient List".

Send to Committers: this email is sent to the person who checked the code during the last build, and the plug-in generates an email address based on the submitter's ID and the (default email suffix) default email suffix of the appended Jenkins configuration page. For example, if the person who submitted the code last time was "first.last" and the default e-mail suffix is "@ somewhere.com", the e-mail will be sent to "first.last@ somewhere.com".

Send To Requester: if checked, the email will be sent to the build trigger.

Include Culprits: if checked, and "Send To Committers" is checked, the email will contain the submitter of the last successful build.

More Configuration: you can make more individual settings for each mail trigger by clicking the "+ (expand)" link.

Recipient List: this is a list of acceptable email addresses separated by commas (or spaces). If triggered, send an email to the list. The list is appended to "Global Recipient List".

Subject: specifies the subject of the selected message. Note: the mail trigger type in the advanced options can override the configuration for it.

Content: specifies the content body of the selected message. Note: the mail trigger type in the advanced options can override the configuration for it.

Remove you can delete a trigger by clicking the "Delete" button that specifies the current row of the trigger.

2.2.1.2 trigger type

Note: all triggers can only be configured once.

Failure: send emails that fail to build immediately. If the "Still Failing" trigger is configured and the status of the last build was "Failure", the "Still Failing" trigger will send an email instead.

Unstable: instantly send emails that are not firmly built. If the "Still Unstable" trigger is configured and the status of the last build is "Unstable", then "Still"

The "Unstable" trigger will send an email instead.

Still Failing: if the status of two or more consecutive builds is "Failure", send this message.

Success: send mail if the status of the build is "Successful". If "Fixed" is configured and the status of the last build is "Failure" or "Unstable", the "Fixed" trigger will send an email instead.

Fixed: sends a message when the build status changes from "Failure" or "Unstable" to "Successful".

Still Unstable: if the status of two or more consecutive builds is "Unstable", send this message.

Before Build: send an email when the build begins.

2.2.1.3 Project mail variables

Note: only the missing variables on the global configuration page are explained here.

${DEFAULT_SUBJECT}: this is the message subject configured by default on the Jenkins system configuration page

${DEFAULT_CONTENT}: this is the mail content body configured by default on the Jenkins system configuration page

${PROJECT_DEFAULT_SUBJECT}: this is the default email subject for the project. The result of using this token in the advanced configuration takes precedence over the Default Subject field. Warning: do not use this token in Default Subject or Default Content, it will produce an unknown result.

${PROJECT_DEFAULT_CONTENT}: this is the default mail content body for the project. The result of using this token in the advanced configuration takes precedence over Default

Content field. Warning: do not use this token in Default Subject or Default Content, it will produce an unknown result.

3 Jelly script

Starting with Jenkins 2.9, we can use Jelly scripts. The Jelly script is linked to Hudson's API and can get any information you want, so it's powerful. The plug-in has two packaged Jelly scripts, which you can customize.

There are two default Jelly scripts in the plug-in: one is used to design messages in HTML format, and the other is to define messages in TEXT format. You can specify which script the plug-in calls by using template parameters. They are used as follows:

Text format: ${JELLY_SCRIPT,template= "text"}

HTML format: ${JELLY_SCRIPT,template= "html"}

You can also write your own Jelly scripts. Jelly scripts are particularly powerful because they can be linked to Jenkins's API, including hudson.model.AbstractBuild and hudson.model.AbstractProject. If you plan to do this, you can first refer to the existing html and text scripts to find out. It is worth noting that having Hudson administrator privileges is a prerequisite for using a custom Jelly script that is not packaged with email-ext. The steps for generating the script itself are relatively simple:

1. Create a Jelly script. The name of the script should be .jelly. It is important that the name ends with. Jelly.

two。 Store the script in the JENKINS_HOMEemail-templates folder.

3. Use the Jelly variable to have template match your script name (do not include a suffix). For example, if the name of the script is foobar.jelly, the message should read ${JELLY_SCRIPT,template= "foobar"}. The following two figures are the emails generated using the Jelly script (the latest version of Email-ext adds a html_gamil template, which is similar to the html template, so a screenshot of it is no longer shown):

After reading the above, do you have any further understanding of how to use email-ext to replace the default email notification for Jenkins? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.