Jenkins触发构建--事件触发

事件触发

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

由上游任务触发

当B任务的执行依赖A任务的执行结果时，A就被称为B的上游任务。

在Jenkins 2.22及以上版本中，trigger指令开始支持upstream类型的触发条件。upstream的作用就是能让B pipeline自行决定依赖哪些上游任务。

1. triggers {
2.     upstream(upstreamProjects: 'job1,job2', threshold: hudson.model.Result.SUCCESS)
3. }

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

• ABORTED 任务被手动中止
• FAILURE 构建失败
• SUCCESS 构建成功
• UNSTABLE 存在一些错误，但不至于构建失败
• NOT_BUILT 在多阶段构建时，前面阶段的问题导致后面阶段无法执行

注意：这种需要手动构建当前任务一次，让jenkins加载pipeline后，trigger指令才生效

gitlab通知触发

gitlab通知触发是指当gitlab发现源代码有变化时，触发jenkins执行构建。 由gitlab主动通知进行构建的好处是显而易见的，这样很容易就解决了我们之前提到的轮询代码仓库时“多久轮询一次”的问题，实现每一次代码变化都对应一次构建。

1.安装jenkins插件 安装Generic Webhook Trigger Plugin、git、Gitlab API Plugin、GitLab Plugin插件，注意不是gitlab hook插件（已废弃）

2.在gitlab创建一个项目，test-a，地址http://1.1.1.1/book/test-a

3.在jenkins上创建pipelien项目，可以同名称test-a。正常在不使用pipeline进行这个触发配置的时候，也可以用页面进行配置，勾选相当于开始接收外界发来的请求。

这里要注意，上面标注的URL是固定输出的信息，实际项目地址要看WEB栏，这个才是真实地址的

4.生成个人API的Token，用于安全验证

5.在gitlab项目的设置里，配置钩子

URL填入如下 http://账号名:刚才生成的Token@Jenkins的地址/job/test-a/build?job=test-a&token=随机写个项目token，这里随便打

现在网络上可能有各种配置，可能老版本适用，但我用的2.220就各种用不了，最后从官网找到这个能用的配置。

为什么这么配置： gitlab代码有更新，就会通过上面这个url，将一些请求和相关内容通过post方式传给Jenkins。Jenkins发现你的test-a项目开启了这个触发功能，就会根据pipeline的配置进行相应处理，符合条件后就会触发执行。

如果只粘贴Jenkins web配置中显示的地址 Token，会报错403问题。这是因为如果没指定账号密码，gitlab只能通过匿名用户去访问Jenkins去传参。

但现在大多全局安全配置里，是Role-Based Strategy插件方式管理的

往上都说403要这样，我感觉是真的蠢，这样会不安全，而且插件管理和这个只能选择一个。

6.编写pipeline，要保存执行一下这个job让配置生效，具体的参数含义在末尾

1. pipeline {
2. agent any
3. triggers {
4. gitlab(triggerOnPush: true,
5. triggerOnMergeRequest: true,
6. branchFilterType: "All",
7. secretToken: "t8vcxwuza023ehzcftzr5a74vkpto6xr")
8. }
9. stages {
10. stage('pull') {
11. steps {
12. echo '拉取代码'
13. }
14. }
15. }
16. }

会发现这里自动勾上了，这是因为pipeline其实就是配置的这个选项，但版本化管理会更好

7.在gitlab上点击一下触发，看是否jenkins job被触发了

8.然后在gitlab项目中，随意修改个文件，看是否也能自动触发

9.参数含义

1. riggerOnPush: 当Gitlab触发push事件时，是否执行构建
2. triggerOnMergeRequest: 当Gitlab触发mergeRequest事件时，是否执行构建
3. branchFilterType: 只有符合条件的分支才会触发构建，必选，否则无法实现触发。
4. All: 所有分支
5. NameBasedFilter: 基于分支名进行过滤，多个分支名使用逗号分隔
6. includeBranchesSpec: 基于branchFilterType值，输入期望包括的分支的规则
7. excludeBranchesSpec: 基于branchFilterType值，输入期望排除的分支的规则
8. RegexBasedFilter: 基于正则表达式对分支名进行过滤
9. sourceBranchRegex: 定义期望的通过正则表达式限制的分支规则
10. secretToken： 指定这个job_name的token验证字符

如果只允许master分支push后才触发，就如下配置，token使用了全局变量，这样多个项目都可以用一个token，比较方便（内网比较适合）

1. riggers {
2. gitlab(triggersOnPush: true,
3. triggersOnMergeRequest: true,
4. branchFilterType: "NameBasedFilter",
5. includeBranchesSpec: "master",
6. secretToken: "${env.git_token}")
7. }

用正则匹配，适合对分支号进行规则定义的项目

1. triggers {
2. gitlab(triggersOnPush: true,
3. triggersOnMergeRequest: true,
4. branchFilterType: "RegexBasedFilter",
5. sourceBranchRegex: "dev.*",
6. secretToken: "${env.git_token}")
7. }