赵走x博客 - 开发者的网上家园

34、触发pipeline执行：事件触发

资源编号:76409 Jenkins 2.x 实战指南微服务热度：28

事件触发就是发生了某个事件就触发pipeline执行。这个事件可以是你能想到的任何事件。比如手动在界面上触发、其他job主动触发、HTTP API Webhook触发等。

# 1、 由上游任务触发：upstream

当B任务的执行依赖A任务的执行结果时，A就被称为B的上游任务。在Jenkins 2.22及以上版本中，trigger指令开始支持upstream类型的触发条件。upstream的作用就是能让B pipeline自行决定依赖哪些上游任务。示例如下：

![bs64](https://img.handsomemark.com/2020/03/04/51b9195c-5df9-11ea-90b7-0242ac120003.png)

当upstreamProjects参数接收多个任务时，使用，分隔。threshold参数是指上游任务的执行结果是什么值时触发。hudson.model.Result是一个枚举，包括以下值：

• ABORTED：任务被手动中止。

• FAILURE：构建失败。

• SUCCESS：构建成功。

• UNSTABLE：存在一些错误，但不至于构建失败。

• NOT_BUILT：在多阶段构建时，前面阶段的问题导致后面阶段无法执行。

>注意：需要手动触发一次任务，让Jenkins加载pipeline后，trigger指令才会生效。

# 2、 GitLab通知触发

GitLab通知触发是指当GitLab发现源代码有变化时，触发Jenkins执行构建。示意图如图6-1所示。

![bs64](https://img.handsomemark.com/2020/03/04/6e762be8-5df9-11ea-93cf-0242ac120003.png)
图6-1 开发推代码触发Jenkins执行构建
由GitLab主动通知进行构建的好处是显而易见的，这样很容易就解决了我们之前提到的轮询代码仓库时“多久轮询一次”的问题，实现每一次代码的变化都对应一次构建。

安装GitLab的过程就不赘述了。假设已经安装好GitLab，其配置过程并不复杂。通过以下几步就可以实现提交代码后，GitLab触发Jenkins上相应的pipeline执行构建。

（1）安装Jenkins插件。

• GitLab插件（https://plugins.jenkins.io/gitlab-plugin ）。

• git插件（https://plugins.jenkins.io/git ）。

需要再次提醒的是，本书使用的GitLab版本是10.5.4，使用的是GitLab插件，不是GitLab Hook插件（已废弃）。在安装插件时需要留意。

（2）在GitLab上创建项目。我们在jenkins-book这个group下创建一个名为“hello-world-pipeline”的项目，地址为：http://192.168.0.100：8091/jenkins-book/hello-world-pipeline 。

（3）在Jenkins上创建pipeline项目（注意是单分支的pipeline项目，而不是多分支的pipeline项目）。使用的git地址就是上一步创建的git@192.168.0.100：jenkins-book/hello-world-pipeline.git。Jenkins将使用SSH方式拉取，所以需要提前将SSH的公钥放到GitLab上。

（4）在Jenkins上配置hello-world-pipeline。在项目的配置页中找到“Build Triggers”部分，勾选“Build when a change is pushed to GitLab”复选框，就可以看到如图6-2所示的配置。

![bs64](https://img.handsomemark.com/2020/03/04/a7fcd3d0-5df9-11ea-a492-0242ac120003.png)
图6-2 配置GitLab触发
可以看到Jenkins会暴露一个webhook：http://192.168.23.11:8667/jenkins/project/hello-world-pipeline 。

这里需要提醒读者朋友，不论是单分支的pipeline项目还是多分支的pipeline项目，它们暴露的webhook的地址格式都是：`/project/＜项目名＞`，而不是`/job/＜项目名＞`。

那是不是说任何人都可以请求这个webhook？这取决于你在Jenkins上的权限设置。总的来说，这个webhook调用权限取决于以下两个设置项：

• Jenkins全局权限设置。

• 该pipeline是否设置了“Secret token”。

不论Jenkins全局权限如何设置，基于安全的考虑，我们一般都会为该pipeline生成一个Secret token，只有带上Secret token的请求才会被处理。Secret token的生成也很简单。单击如图6-2所示页面上的“Advanced”按钮，我们就可以看到一个“Secret token”输入框，推荐单击其右下角的“Generate”按钮自动生成Secret token，而不是手动输入，如图6-3所示。

![bs64](https://img.handsomemark.com/2020/03/04/ca0af8f8-5df9-11ea-8ef4-0242ac120003.png)
图6-3 自动生成Secret token
我们需要将所生成的Secret token复制下来，在接下来的步骤中会使用到。

（5）GitLab：配置通知Jenkins。

进入hello-world-pipeline在GitLab上的配置页，找到Settings→Integrations（注意不同版本的GitLab，界面可能不同），如图6-4所示。

![bs64](https://img.handsomemark.com/2020/03/04/d572637a-5df9-11ea-b621-0242ac120003.png)
图6-4 配置GitLab

在Integrations配置页的相应输入框中粘贴上一步中Jenkins暴露的webhook及相应的Secret token，如图6-5所示。

![bs64](https://img.handsomemark.com/2020/03/04/e0355470-5df9-11ea-8a23-0242ac120003.png)
图6-5 设置Secret token
（6）测试整个链路是否通了。

在GitLab上添加好这个webhook后，可以跳到表单下方，有一个已添加的webhook列表，找到我们刚刚创建的webbook。单击“Test”按钮，选择“Push events”，GitLab就会向该webhook发送一个event，如图6-6所示。

![bs64](https://img.handsomemark.com/2020/03/04/eafc0a98-5df9-11ea-87fc-0242ac120003.png)
图6-6 测试链路是否通了
再回到Jenkins上该项目的详情页，在构建历史中，我们可以看到被GitLab触发的构建都会被标记为“Started by GitLab push by Administrator”，如图6-7所示。这就说明链路已经通了。

![bs64](https://img.handsomemark.com/2020/03/04/f04ccc62-5df9-11ea-8a85-0242ac120003.png)
图6-7 Jenkins任务被GitLab事件触发

# 3、在pipeline中实现GitLab trigger

对于以上步骤，需要手动做的还不少。首先需要在Jenkins界面上手动勾选“Build when a change is pushed to GitLab”复选框，还需要手动单击“Generate”按钮生成Secret token或手动输入Secret token。

这部分手动操作，我们也希望通过修改Jenkinsfile就能实现。显然，不只是我们这样想，早就有人想到了，并在GitLab插件上实现了基于GitLab的trigger。以下是具体使用方法。

![bs64](https://img.handsomemark.com/2020/03/04/00c3ccc6-5dfa-11ea-9010-0242ac120003.png)

secretToken使用随机字符串生成器生成即可。如果Jenkins在内网使用，并且安全性有一定的保障，我们可以将secretToken定义为一个Jenkins全局变量，供所有的项目使用。这样做就不用为每个项目重新生成token了。

GitLab trigger方法有很多参数可配置，下面简单介绍一些常用的参数。

• triggerOnPush：当GitLab触发push事件时，是否执行构建。

• triggerOnMergeRequest：当GitLab触发mergeRequest事件时，是否执行构建。

• branchFilterType：只有符合条件的分支才会被触发。必选，否则无法实现触发。可以设置的值有：

◦ NameBasedFilter：基于分支名进行过滤，多个分支名使用逗号分隔。

◦ RegexBasedFilter：基于正则表达对分支名进行过滤。

◦ All：所有分支都会被触发。

• includeBranchesSpec：基于branchFilterType值，输入期望包括的分支的规则。

• excludeBranchesSpec：基于branchFilterType值，输入期望排除的分支的规则。

想了解更多的参数，可以在GitLab plugin的GitHub页面中查看。