Jenkins is a popular CI continuous integration tool that enables automated project building, packaging, testing, publishing, and more. You can also send mail notifications after a build fails, when you build an unstable state, and so on. Here's how to configure messaging notifications in Jenkins. In Jenkins, which implements mail notification, Jenkins provides two ways to configure it. One is that Jenkins has a built-in default email notification, but it has many limitations, such as its email notifications not providing detailed message content, the inability to define the format of sending messages, the inability to define flexible message reception configurations, and so on. The other is to use the plugin to send email notifications by installing the email Extension plugin plugin. Both the global configuration and the project configuration are available for any type of mail notification. The global configuration is set in the system settings of the system management in Jenkins, and the project configuration is set in the configuration of the specific project. The following describes the configuration of the two mail notifications for Jenkins. The Jenkins version in the example is Jenkins ver. 2.27
first, Jenkins built-in default email notification configuration1. Global Configuration Click on the "System Management" menu on the left, select "System Settings" on the right to find the Jenkins Locaction entry in the system settings to fill in the Jenkins URL and the system administrator email address, the system administrator e-mail address must be configured, or not send mail notification. Because mail notifications are sent by the system administrator's mailbox. Find the email notification entry, fill in the SMTP server information and user name, password and other authentication information. When you are ready, check "test configuration by sending test mail" to the address of the receiving test message and click "Test Config". If the configuration is correct, email was successfully sent in the test receive mailbox will receive a test message sent by the Jenkins system Administrator's mailbox. Note that the mailbox notification is indeed configured correctly and can send and receive Jenkins's notification messages properly. A netizen said that if the sending mailbox is a mail service provider such as 163 of the mail, the receiving mailbox must be equipped with the same mail service provider 163 to receive the mail, after testing no such restrictions, as long as it is able to send and receive e-mail casually with which mail service providers 126, 163, QQ, 189 even the company mail, etc. can be received. 2, the project configuration Mail notification of the global settings are ready to be used in specific projects to send email notifications. In the project's settings, find the "Add build Operation Steps", select "E-mail Notifacation" by e-mail notification. In recipients, if more than one recipient is separated by a space, you can send an email notification to multiple related recipients. If the configuration is not a problem, there will be an email notification to the email notification recipient when the problem is built.
Second, email Extension plugin plugin configuration Email notification1, the global configuration also click on the left of the "System Management" menu, select the right "system settings", find extend e-mail notification for global configuration. Also fill in the information for the SMTP server. Click "Advanced" to configure the SMTP authentication, configure the sender's user name, password and other information. The default recipient fills in the person who needs to send the email notification, if there are multiple "default Triggers ..." buttons in the bottom-right corner of the box that are separated by a space to set the event that triggers the mail notification. Select the event that will trigger the email notification, as appropriate. After you save the global configuration information, the project is configured in the project. 2, the project configuration into the specific project configuration interface Click "Configure", in the Configuration interface click on the "Add build after Operation", select "Editable Email Notification" in the settings to save the default is OK. You can personalize the project for this item in "Advanced Settings". You can define the recipient list, subject, content, attachments, and so on for this project notification. Click Save when you are finished setting up. You can verify that you can notify the email. After the test project is built, the messaging recipient of the Jenkins configuration can receive the message notification of the build message normally. Here Jenkins configures email notifications to complete. ======================================
e-mail notification configuration related global properties detailed1. 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 settings that are different from ( default options). 2. default content type: Specifies the type of message content sent after build, with text and HTML two kinds of .3. use list-id email Header: Set a List-id message header for all messages 4. add ' Precedence: bulk ' email header: Set priority 5. Default recipients: Customize the default e-Mail recipient list. If not overridden by the project configuration, the plugin will use 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: e-mail address for example, Cc:[email protected]6. reply to list: Reply list, a comma separated list of e-mail addresses to use in the reply-to header of the email. this value will be available as $ Default_replyto in the project configuration.7. emergency reroute: If this field is not empty, All e-mails will be sent separately to that address (or address list). 8. excluded committers: To prevent messages from being considered spam by the mail system, the mailing list should not have an extended account name (for example: @domain. com), and use commas to separate 9. defAult subject: The default theme name for custom mail notifications. This option can replace some parameters in the subject field of the message so that you can include the specified output information in the build. 10. maximum attachment size: Maximum message attachment size. 11. default content: The default content body for custom mail notifications. This option can replace some parameters in the contents of the message so that you can include the specified output information in the build. 12. default pre-send script: script executed before default (note: Grooy script, which I see in an article, is not necessarily accurate). 13. enable debug mode: Enables the debug mode of the plugin. This will add additional log output, build logs, and Jenkins logs. Useful when debugging, but not for production. 14. enable security: When enabled, the ability to send scripts is disabled and goes directly to the Jenkins instance. If a user tries to access a Jenkins managed object instance, a security exception is thrown. 15. content token reference: Variables that can be used in a message, all of which are optional.
Global Message Variables The Email-ext plugin allows you to use variables to dynamically insert data into the subject of the message and the content. A variable is a string that starts with a $ (dollar sign) and ends with a space. When a message is triggered, all variables of the subject and content body fields are dynamically replaced by real values. Similarly, the "value" in a variable can contain other variables, and will be replaced with the actual content. For example, the default theme and content for the project configuration page are 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 default_content of the project configuration page, so it also automatically uses the project's configuration. Because the value in a variable can contain other variables, you can quickly create different pointcuts for the variable: global level (all projects), exclusive level (single project), trigger level (build result). If you want to see all available variables, you can click on the content token reference question mark on the configuration page to get detailed information. All variables are optional, each variable can be represented as follows, the string type uses name= "value", and the Boolean and numeric types use Name=value. If there are no variables inside the {and} tags, they will not be parsed. Example: $TOKEN, ${token},${token,count=100},${env,var= "PATH"} Hint: use commas to separate arguments of variables. Common properties are as follows: ${file,path= "path"} includes the content of the specified file (path) relative to the workspace root directory. Path file paths, note: is the relative path to the workspace directory. ${build_number} Displays the number of the current build. ${job_description} Displays the item description. ${svn_revision} Displays the SVN version number. The svn_revision_n version of the Subversion plugin export is also supported. ${cause} shows who, through what channels, triggered this build. ${changes } -shows the changes since the last build. showpaths if it is true, the address after which the modification is submitted is displayed. False by default. showdependencies If True, the project build dependency is displayed. The default is falseformat traversal commit information, a string containing%x, where%a represents the author, and%d represents the date,%m represents the message,%p represents the path, and%r represents the version. Note that not all versions of the system support%d and%r. If the specified showpaths is ignored. Default "[%a] %m\\n". pathformat a string containing "%p" to indicate how to print the path. ${BUILD_ID} Displays the ID of the current build build. ${project_name} Displays the full name of the project. ${project_display_name} Displays the display name of the item. ${script} generates custom message content from a script. The custom script should be placed in "$JENKINS _home/email-templates". The $jenkins_home/email-templatesdirectory directory is searched by default when using a custom script. Other directories will not be searched. script when it is used, only the last value is used by the script (cannot use both scripts and template). Template for regular simpletemplateengine format. ${jenkins_url} Displays the URL address of the JENKINS server (you can then change the System Configuration page). ${build_log_multiline_regex} matches and displays the build log by regular expression. regex java.util.regex.pattern builds the build log for regular expression matching. No default value, can be null. The maximum number of maxmatches matches. If 0, all will be matched. The default is 0. showtruncatedlines if True, contains [... truncated ### lines ...] Yes. The default is true. substtext if not empty, insert this part of the text (instead of the entire line) into the message. The default is empty. escapehtml If True, the HTML is formatted. The default is False. matchedsegmenthtmlstyle if not NULL, the output HTML. The number of rows that match will change to <b style= "Your-style-value" > html escaped matched line </b> Format. The default is empty. ${build_log} shows the final constructionBuild logs. maxlines the maximum number of rows displayed in the log, the default is 250 rows. escapehtml If True, the HTML is formatted. False by default. ${project_url} Displays the URL address of the item. ${build_status} -shows the status of the current build (failure, success, and so on) ${build_url} -displays the URL address of the current build. ${changes_since_last_success} -shows the changes since the last successful build. The reverse is marked with a recent build at the top. False by default. Format iterates through the build information, a string containing%x, where%c is the change of all,%n is the build number. Default "changes for build #%n\n%c\n". The Showpaths,changesformat,pathformat defines the showpaths, format, and Pathformat parameters, respectively, such as ${changes}. The ${changes_since_last_unstable} -display shows the changes after the last shaky or successful build. The reverse is marked with a recent build at the top. The default false format iterates through the build information, a string containing%x, where%c is the change for all, and%n is the build number. Default "changes for build #%n\n%c\n". The Showpaths,changesformat,pathformat defines the showpaths, format, and Pathformat parameters, respectively, such as ${changes}. ${env} – displays an environment variable. var– displays the name of the environment variable. If blank, all is displayed and the default is empty. ${failed_tests} -If there are failed tests, these failed unit test information is displayed. ${jenkins_url} -Displays the address of the JENKINS server. (You can change it on the "System Configuration" page). ${hudson_url} -not recommended, use $jenkins_url${project_url} -to display the URL of your project. ${svn_revision} -shows the version number of SVN. ${jelly_script} -to customize the message content from a JELLY script template. There are two types of templates to configure: HTML and text. You can replace it by customizing it under $jenkins_home/email-templates. When using auto-defined templates, the name of the "template" parameter does not contain ". Jelly". Template name, default "HTML". ${test_counts} -shows the number of tests. var– default "Total". total -the quantity of all tests. fail -the number of failed tests. skip -skips the number of tests.
Original: 53024562
Jenkins Configure email Notifications
