一、系统管理

系统设置

一般不需要改动什么。

Email Extension Plugin配置
下面的配置是针对发送邮件的配置，我使用的是163的smtp来发送，大家可以指定其他邮箱。
1、系统管理－系统设置，先设置发件人的邮件，切记：一定要设置，且在系统管理员那个地方设置的email地址要和email配置的相同

2、大家可以在下面的 邮件通知 里面测试是否能够发送成功，如果收到以下邮件，恭喜　This is test email #1 sent from Jenkins

3、在构建中使用
要想在一个项目中使用email-ext插件，你首先必须在项目配置页激活它。在构建后操作——”增加构建后操作步骤”选项中勾选”Editable Email Notification”标签。如下图：

下面的触发器里面选择”Always”的时候发送默认的邮件配置

4、下面给出我的标题和内容的配置，方便大家ctrl+c ctrl+v

Default Subject



构建通知:${BUILD_STATUS} - ${PROJECT_NAME} - Build # ${BUILD_NUMBER} !

Default Content



<!DOCTYPE html>

<html>

<head>

<meta charset="UTF-8">

<title>${ENV, var="JOB_NAME"}-第${BUILD_NUMBER}次构建日志</title>

</head>



<body leftmargin="8" marginwidth="0" topmargin="8" marginheight="4"

    offset="0">

    <table width="95%" cellpadding="0" cellspacing="0"

        style="font-size: 11pt; font-family: Tahoma, Arial, Helvetica, sans-serif">

        <tr>

            <td>(本邮件是程序自动下发的，请勿回复！)</td>

        </tr>

        <tr>

            <td><h2>

                    <font color="#0000FF">构建结果 - ${BUILD_STATUS}</font>

                </h2></td>

        </tr>

        <tr>

            <td><br />

            <b><font color="#0B610B">构建信息</font></b>

            <hr size="2" width="100%" align="center" /></td>

        </tr>

        <tr>

            <td>

                <ul>

                    <li>项目名称&nbsp;：&nbsp;${PROJECT_NAME}</li>

                    <li>构建编号&nbsp;：&nbsp;第${BUILD_NUMBER}次构建</li>

                    <li>SVN&nbsp;版本：&nbsp;${SVN_REVISION}</li>

                    <li>触发原因：&nbsp;${CAUSE}</li>

                    <li>构建日志：&nbsp;<a href="${BUILD_URL}console">${BUILD_URL}console</a></li>

                    <li>构建&nbsp;&nbsp;Url&nbsp;：&nbsp;<a href="${BUILD_URL}">${BUILD_URL}</a></li>

                    <li>工作目录&nbsp;：&nbsp;<a href="${PROJECT_URL}ws">${PROJECT_URL}ws</a></li>

                    <li>项目&nbsp;&nbsp;Url&nbsp;：&nbsp;<a href="${PROJECT_URL}">${PROJECT_URL}</a></li>

                </ul>

            </td>

        </tr>

        <tr>

            <td><b><font color="#0B610B">Changes Since Last

                        Successful Build:</font></b>

            <hr size="2" width="100%" align="center" /></td>

        </tr>

        <tr>

            <td>

                <ul>

                    <li>历史变更记录 : <a href="${PROJECT_URL}changes">${PROJECT_URL}changes</a></li>

                </ul> ${CHANGES_SINCE_LAST_SUCCESS,reverse=true, format="Changes for Build #%n:<br />%c<br />",showPaths=true,changesFormat="<pre>[%a]<br />%m</pre>",pathFormat="&nbsp;&nbsp;&nbsp;&nbsp;%p"}

            </td>

        </tr>

        <tr>

            <td><b>Failed Test Results</b>

            <hr size="2" width="100%" align="center" /></td>

        </tr>

        <tr>

            <td><pre

                    style="font-size: 11pt; font-family: Tahoma, Arial, Helvetica, sans-serif">$FAILED_TESTS</pre>

                <br /></td>

        </tr>

        <tr>

            <td><b><font color="#0B610B">构建日志 (最后 100行):</font></b>

            <hr size="2" width="100%" align="center" /></td>

        </tr>

        <!-- <tr>

            <td>Test Logs (if test has ran): <a

                href="${PROJECT_URL}ws/TestResult/archive_logs/Log-Build-${BUILD_NUMBER}.zip">${PROJECT_URL}/ws/TestResult/archive_logs/Log-Build-${BUILD_NUMBER}.zip</a>

                <br />

            <br />

            </td>

        </tr> -->

        <tr>

            <td><textarea cols="80" rows="30" readonly="readonly"

                    style="font-family: Courier New">${BUILD_LOG, maxLines=100}</textarea>

            </td>

        </tr>

    </table>

</body>

</html>

下面就是重要的 Publish over SSH 插件了

这是高级配置中的内容，可以指定ssh的密码以及私钥、端口、代理等内容

全局安全设置(Configure Global Security)

默认的Jenkins不包含任何的安全检查，任何人可以修改Jenkins设置，job和启动build等。显然地在大规模的公司需要多个部门一起协调工作的时候，没有任何安全检查会带来很多的问题。在系统管理－Configure Global Security页面可以“访问控制”进行相应的设置。如下图：

Jenkins的权限配置文件存放在JENKINS_HOME目录。进入JENKINS_HOME目录，找到config.xml文件。打开config.xml，里面有一堆的东西，找找。。。找到了和节点。节点代表是否使用用户权限，节点代表用户权限是怎么划分的。

1） Security Realm，用来决定用户名和密码，且指定用户属于哪个组；
2） Authorization Strategy，用来决定用户对那些资源有访问权限；

一、详细讲解4种授权策略

1、任何用户可以做任何事（没有任何限制）
1）页面设置如下图：

2）config.xml脚本如下：

<useSecurity>true</useSecurity>

  <authorizationStrategy class="hudson.security.AuthorizationStrategy$Unsecured"/>

  <securityRealm class="hudson.security.HudsonPrivateSecurityRealm">

    <disableSignup>true</disableSignup>

    <enableCaptcha>false</enableCaptcha>

  </securityRealm>

2、登录用户可以做任何事
1）页面设置如下图：

2）config.xml脚本如下：

<useSecurity>true</useSecurity>

  <authorizationStrategy class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy"/>

  <securityRealm class="hudson.security.HudsonPrivateSecurityRealm">

    <disableSignup>false</disableSignup>

    <enableCaptcha>false</enableCaptcha>

  </securityRealm>

3、安全矩阵
1）页面设置如下图：

2）config.xml脚本如下：

<useSecurity>true</useSecurity>

  <authorizationStrategy class="hudson.security.GlobalMatrixAuthorizationStrategy">

    <permission>hudson.model.Hudson.Administer:jenkins</permission>

    <permission>hudson.model.Hudson.Read:anonymous</permission>

    <permission>hudson.model.Hudson.Read:dev</permission>

    <permission>hudson.model.Item.Build:dev</permission>

    <permission>hudson.model.Item.Read:anonymous</permission>

    <permission>hudson.model.Item.Read:dev</permission>

  </authorizationStrategy>

  <securityRealm class="hudson.security.HudsonPrivateSecurityRealm">

    <disableSignup>false</disableSignup>

    <enableCaptcha>false</enableCaptcha>

  </securityRealm>

设置好权限之后，点击注册，注册相应的账号，如上图的dev,jenkins。

4、项目矩阵授权策略
说明：安全矩阵和项目矩阵授权策略的配置是一模一样的，唯一的区别是项目矩阵授权策略支持在Job的配置页面再次配置授权策略。

这种策略在工作中用得较多，比如针对不同的项目选择不同的用户具有不同权限。
1）页面设置如下图：

各种权限如下(在配置页面将鼠标放到该权限上即可查看帮助)：

其中有一些比较特别的权限：
最大的权限是Overall的Administer，拥有该权限可以干任何事情。
最基本的权限是Overall的Read，用户必须赋予阅读的权限，不然什么都看不到。
Job的Discover权限是一个奇葩的权限，帮助说Discover比Read的级别更低。如果匿名用户(没有访问job的权限)直接访问一个Job的Url将重定向到登陆页面。(经测试，这个权限应该是被废弃了。)
Credentials的ManageDomains这个权限没有看懂干嘛的，有懂的大家一起交流哈！
ps：如果有个用户被赋予了Overall的Read，并没有被赋予Job的Read权限，那么该用户就无法访问job。原因：没有权限。

2）config.xml脚本如下：

<useSecurity>true</useSecurity>

  <authorizationStrategy class="hudson.security.ProjectMatrixAuthorizationStrategy">

    <permission>hudson.model.Hudson.Administer:admin</permission>

    <permission>hudson.model.Hudson.Read:anonymous</permission>

    <permission>hudson.model.Item.Build:dev</permission>

    <permission>hudson.model.Item.Read:anonymous</permission>

    <permission>hudson.model.Item.Read:dev</permission>

  </authorizationStrategy>

  <securityRealm class="hudson.security.HudsonPrivateSecurityRealm">

    <disableSignup>false</disableSignup>

    <enableCaptcha>false</enableCaptcha>

  </securityRealm>

3）每个用户后都有1-2个图标，第一个是反选功能(删除当前已选择的权限，选择其他所有权限)，第二个是删除功能(删除该用户)

4）在Job中配置项目安全，如下图：

最后给大家说说在配置文件里面怎么辨别使用是哪种权限控制模式

节点上有个class属性，这个属性控制着使用那种授权模式。

登录用户可以做任何事:
hudson.security.FullControlOnceLoggedInAuthorizationStrategy
项目矩阵授权策略:
hudson.security.ProjectMatrixAuthorizationStrategy
安全矩阵:
hudson.security.GlobalMatrixAuthorizationStrategy
遗留模式:
hudson.security.LegacyAuthorizationStrategy

全局设置(Global Tool Configuration)

这里没什么好讲的，配置就对了。

二、Job配置

General

丢弃旧的构建：这项功能主要是为了节省服务器空间，我设置为“保持构建的最大个数”为30，超过的Jenkins会自动删除旧的构建。 



安静期：一个计划中的构建在开始之前需要等待选项中设置的秒数



重试次数：如果从版本库签出代码失败,Jenkins会按照这个指定的次数进行重试之后再放弃.

源码管理

git和subversion的都一样的配置，基本都是输入一个url和分支，以及认证信息，其他的选项根据自己的需要配置，当然你也可以不适用源码管理。选择None。

构建触发器&构建环境

这里我没怎么选，我把执行的操作都放在了构建和构建后操作中。

构建

这里我执行的shell命令大概的意思是，进行打包上传阿里云服务器，然后执行服务器上的一个脚本kill-tomcat-force.sh

这里放上两个脚本：

#!/bin/bash

JENKINS_HOME="/Users/benjamin/.jenkins"

PROJECT="hotelsupplies"

WORKSPACE="$JENKINS_HOME"/workspace

TARGET="target"

FULL="$WORKSPACE"/"$PROJECT"/"$TARGET"

ALIYUN="root@121.42.169.178"



#cd ~/.jenkins/workspace

#git clone https://github.com/benjaminwhx/hotelsupplies.git --depth=1

cd ~/Desktop/hotelsupplies

mvn clean install -Dmaven.test.skip=true

echo "maven打包成功"



if [ ! -d "$WORKSPACE"/"$PROJECT"/"$TARGET" ]; then

	mkdir -p "$FULL"

fi

cp "$TARGET"/"$PROJECT".war "$FULL"

echo "war package prepare for send to ALiYun!!!"



scp "$FULL"/"$PROJECT".war "$ALIYUN":/root/server

echo "war包上传成功!"

# settings

# 不export JAVA_HOME就会出现Neither the JAVA_HOME nor the JRE_HOME environment variable is defined错

export JAVA_HOME=/usr/local/jdk1.8.0_73

TOMCAT_PORT="80"

TOMCAT_HOME="/root/server/apache-tomcat-8.0.32"

PROJECT="hotelsupplies"

SERVER="/root/server"



if [ ! -e "$SERVER"/"$PROJECT".war ]; then

  echo "$PROJECT".war "文件不存在，结束当前执行"

  exit;

fi



# tomcat bin folder

path="/root/server/apache-tomcat-8.0.32/bin"



# shutdown tomcat

"$path"/shutdown.sh

echo "tomcat关闭"



# kill tomcat pid

kill -9 $(lsof -i:80 |awk '{print $2}'| tail -n 2)



# 删除webapps下的项目

rm -rf "$TOMCAT_HOME"/webapps/"$PROJECT".war

mv "$SERVER"/"$PROJECT".war "$TOMCAT_HOME"/webapps

echo "替换webapps下的war包"



# restart tomcat

"$path"/startup.sh

echo "重启tomcat"

echo "finish..."

构建后操作

这里主要是构建完成后发送邮件以及删除指定目录。

以后用的功能多了再进行补充。。。

Jenkins2.3重点备忘

一、系统管理

系统设置

全局安全设置(Configure Global Security)

一、详细讲解4种授权策略

全局设置(Global Tool Configuration)

二、Job配置

General

源码管理

构建触发器&构建环境

构建

构建后操作

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

Jenkins2.3重点备忘

一、系统管理

系统设置

全局安全设置(Configure Global Security)

一、详细讲解4种授权策略

全局设置(Global Tool Configuration)

二、Job配置

General

源码管理

构建触发器&构建环境

构建

构建后操作

热门文章

最新文章

相关课程

相关电子书

相关实验场景