Centos7 Jenkins构建触发器详解

Last Updated on 2019年10月21日

前言

这一篇，我们来说一下Jenkins的构建触发器，除了手动运行Job进行构建外，默认Jenkins提供了5种方式的触发构建，maven项目多一种，可以让我们通过别的方式触发来实现Job的自动构建。

这里我将一一的进行详细说明，主要包括如下几种触发方式，其中github和gitlab的触发这里只讲gitlab，因为国内大多公司都是使用gitlab作为代码仓库，较少会用github进行开发。

这里具体详细说明的触发方式如下：

Build whenever a SNAPSHOT dependency is built
Trigger builds remotely (e.g., from scripts)
Build after other projects are built
Build periodically
Build when a change is pushed to GitLab. GitLab webhook URL: http://jenkins.example.com/project/test
Poll SCM

由于触发方式较多，此文章可能会较长，如果只对其中一些方式感兴趣，可以直接跳到相应方式查看。

正文

1. Build whenever a SNAPSHOT dependency is built

此触发方式是maven项目特有的，在安装Maven Integration插件后，创建maven项目后，触发默认会开启此选项，意思是此项目所依赖的快照有更新则会触发更新此job。

我们知道当maven项目使用mvn命令进行构建时，会到项目配置中设置的本地私服库下载依赖的jar包，比如我们有公共的工具类项目A，此项目中定义一些公司自定义的工具类，代码更新后会使用mvn deploy命令打成jar包并上传至私服仓库，供相关其他项目依赖使用，那么在项目B中，配置了A的依赖，在构建B项目时，会从私服仓库下载A的jar包，当我们在Jenkins中的项目B的部署Job中配置了Build whenever a SNAPSHOT dependency is built，那么当私服仓库中的A快照有更新时，则会触发Job进行构建。

此触发可以使得保证项目相关依赖都为最新，通常用于测试环境，以保证项目实时为最新状态，当依赖中做来修改，导致代码出错，也能更好的发现。看起来挺好的，但熟悉Jenkins的人会发现，此触发却较少使用。为什么呢，主要有以下几点原因：

在maven项目的开发中，快照版本SNAPSHOT是为了方便开发，以保证maven在编译时都能拉取最新的版本来进行依赖，如果使用release版本号，这样当一个项目更新后，相关依赖他的项目都需要更改pom文件中的版本号才能拉取最新的jar包，因为maven是不会自动应用最新的版本来作为依赖的，这样会导致同时开发多模块时非常的麻烦，效率低下，为了解决这种情况而使用快照版本SNAPSHOT，就可以方便开发，maven编译时会每次都下载最新的依赖快照，不用手动修改pom文件。(这些maven项目的知识，有的运维同学可能不太清楚，可以多了解一些)

如上所说，快照版本SNAPSHOT非常方便，所以在国内，很多不规范的公司会直接将快照版本作为生产版本直接使用，方便直接，这样就会导致其快照版本泛滥，没有release版本，当依赖的模块较多时，在Jenkins中触发就会非常频繁，导致不停的构建。

另外，也由于很多的运维同学，对于Maven项目的不熟悉，对开发流程和开发的工作方式不太了解，所以较少使用此触发器。而解决相应依赖更新则对应项目更新的方式，更多运维同学会通过手动设置Job的关联触发关系来实现。也就是通过Build after other projects are built方式实现，这会在下面细说。

最后，此触发器是否推荐使用呢，不能一言而定，需要根据自身项目的实际情况，依赖情况，还需要配置的人对maven项目和开发流程和方式有一定的了解和熟悉才能自己更好的选择是否使用此触发器。如果你对maven项目不了解，那最好还是关闭此触发器，以避免不可控的情况。

2. Trigger builds remotely (e.g., from scripts)

此触发器实现了通过url远程调用触发Job进行构建。如下图所示，在选中使用此触发器后，需要手动输入验证token，在下面的说明小字中说明了。请求url时需要带上token。请求的url地址也列出来了。

直接请求会发现，返回403，需要验证，因为还需要验证Jenkins用户的登录，这可以通过Jenkins用户的API Token来实现验证。

在界面右上角，进入用户设置，添加API Token，输入名称，点击生成token。

生成token后，就可以通过用户的api token来进行登录验证了。

然后就可以通过请求url来触发构建了，请求的url如下格式，前面的用户名和用户的api token作为Jenkins的登录验证，后面的url路径为Job的触发路径，最后的参数token=example_token为Job中手动设置的验证token。

http://admin:119a8d5f147c20b5d2e4a2ff712c1de69d@jenkins.example.com/view/old_project/job/test/build?token=example_token

通过在脚本中请求此url，则可以触发Job的构建，请求后会返回201状态码，没有返回内容，请求后，到Jenkins上就会看到Job已经执行了，可以自行测试。

另外，此触发器也支持参数化构建，可以在请求中指定参数来实现构建，具体支持什么参数呢，也没明说，具体的我们可以进行测试：

我这里设置了4种最常用的参数：字符串参数，布尔值参数，选择参数，Git分支参数。

然后我们在构建时，直接将这些参数打印出来，方便通过构建日志，看到参数是否传递成功，Git分支参数则通过下载拉起代码查看是否生效

然后请求触发url，在使用参数构建时，使用buildWithParameters代替build，如下：

http://admin:119a8d5f147c20b5d2e4a2ff712c1de69d@jenkins.example.com/view/old_project/job/test/buildWithParameters?token=example_token

PS：使用带参数的构建，需要使用post方法请求，参数还是一样通过url来传递，不是使用body，正常访问还是返回201状态码，需要先设置参数，否则会抱500，提示没有此构建参数。

我这里使用python进行请求，方式如下，类似的通过自己的方式构建url进行请求就可以完成触发。

到Jenkins中，查看构建日志，就会发现参数都传递到了，git分支也传递到了，拉取的分支为指定的分支：

最后，总结一下，此触发方式通过url请求触发，可以在脚本和代码中通过此方法调用Jenkins，这个一般情况下，使用的较少，根据公司实际情况和需求，运维同学可自行考虑是否使用此触发方式。

3. Build after other projects are built

在其他项目构建后执行构建，选中此项后，选择指定的项目(即Job名)，可以选择多个项目，用逗号隔开，如下图

下面有三个选项，分别为：

只在构建成功稳定时才触发
即使构建不稳定也触发
即使构建失败也触发

定义当选中的项目构建状态为什么时，触发此项目的构建，一般都是使用第一个，当指定项目构建成功后，触发此项目进行构建。这样就可以定义此项目的依赖项目，当此项目的依赖项目有更新时，自动触发此项目进行更新。

此触发器比较常用，使用简单，可以简单的实现众多maven项目的依赖触发构建问题，唯一的问题就是，项目新增依赖等，需要手动重新在配置中添加依赖项目，不如使用快照版本触发，直接通过代码通知，不用手动在Jenkins上进行配置。但是快照版本控制需要更好的开发流程和规范。所以很多时候会通过此中方式进行触发，简单直接。

4. Build periodically

定时触发，类似cron配置定时，然后更具配置的定时配置，定时自动触发项目进行构建。

配置方式与crob一样，通过5个*来配置定时计划。格式为：

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  *

具体的配置详情，可以参考《centos7 利用crontab执行定时计划任务》中定时的配置。这里不需要定义执行命令，只需要配置定时就行了。

此触发方式用的较少，因为是完全定时触发，不管是否有更新，都会进行构建。通常会使用Poll SCM来代替此触发方式，关于Poll SCM的详情在后面会说到。

5. Build when a change is pushed to GitLab. GitLab webhook URL: http://jenkins.example.com/project/test

此为Gitlab触发器，通过Gitlab的Webhooks可以发送触发url，触发项目进行构建，实现例如gitlab的代码仓库中代码有新的提交，合并等更新时，触发Jenkins执行Job的构建。

下面详细说一下如何配置使用：

选中此触发后，默认的设置如下，会有一个url，此url用与gitlab中使用webhooks进行触发，gitlab的触发事件很多，这里Jenkins只支持如下几种，一般第一种push events就可以够用了，默认配置可以不需要修改，保持默认即可。

下面还有两个配置比较重要，允许的分支配置，这里可以指定可以触发此Job的分支，默认是全部分支都可以，可以通过Filter branches by name和Filter branches by regex，通过名称或正则匹配，指定可触发的分支，比较常用，一般用于指定master分支或者特殊的分支才进行触发构建。

还有一个Secret token配置，就是安全验证token，点击右下角的Generate会自动生成，在配置gitlab时会用到。

ok，现在到gitlab中去配置触发，进入对应的Gitlab的仓库，在设置中，配置触发的url和上面我们随机生成的Secret token，Url则是在触发器上注明的webhook url。下面我们可以看到有很多的触发事件，默认是只选中了push事件，可以根据你的实际需求和Jenkins能支持的事件，进行多选。

添加webhook后，点击测试push事件，弹出请求成功则配置正确：

然后回到Jenkins的Job中，就可以看到我们刚才点击测试，触发生成的构建Job，如下，会表明触发人：

OK，到此，Gitlab触发器就完成了，就可以实现代码提交，触发Jenkins自动构建，此功能非常常用方便，对于一些简单的又频繁更新的项目等，非常好用。

6. Poll SCM

定时任务，检查代码仓库是否更新，如果有更新则触发构建，没有则不触发。此触发器在Build periodically触发器的基础上，多了一个检查代码是够有更新的判断，这对于需要从代码仓库更新代码进行构建的Job，非常好用，常用于替代Build periodically。

配置方式与Build periodically一样，都是cron的配置方式，只需要定义计划时间就行了，唯一需要注意的是有一个配置：

Ignore post-commit hooks，忽略提交push等提交的钩子触发导致的更新构建，什么意思呢，默认情况下，也就是不勾选此选项时，如果我们同时定义了gitlab的触发器和poll scm触发器两个触发器，当有代码push时，gitlab的钩子webhook会触发Jenkins进行构建，构建时就会更新最新版本代码到工作空间内，当到poll scm定义的时间时，检查发现触发的构建已经更新了代码，代码已经是最新版了，没有需要更新的，所以poll scm不会触发构建。此配置就是忽略由于gitlab webhook和类似的其他hook钩子导致的Jenkins更新，也就是说由于hook钩子触发的代码更新不算，当poll scm定义的时间来临时，会忽略掉hook钩子触发的构建，再此更新代码，重新构建一此。PS：此功能需要scm工具的支持，自版本1.44依赖，svn插件支持此功能。经过我的测试，发现git是不支持的。实际上此选项使用的也比较少，默认是不会勾选的。

OK，到此Poll SCM触发器就说完了，总体来说，也是非常方便好用的触发器，对于一些测试开发环境等可以在半夜触发使其保持最新代码等，实际根据需求进行使用。

结束

OK，Jenkins的触发器就讲到这里，详细讲解说明了Jenkins的默认的6大触发器，大致已经足够我们使用了，大家根据实际的使用情况，自行灵活使用，就可以使Jenkins更加的方便好用。

OK，有任何问题，欢迎留言