jenkins 构建触发器-个人计算机技术知识记录

Jenkins自动化是指项目按照一定的规则自动执行，这些规则被称为项目触发条件。
Jenkins内置支持cron、pollSCM、upstream三种方式。其他方式可以通过插件来实现。

1、Jenkins内置触发器

对于触发条件，可以从两个维度来区分：时间触发和事件触发。

时间触发是指定义一个时间，时间到了就会触发项目执行。
– 定时执行：cron
– 轮询代码仓库：pollSCM
事件触发就是发生了某个事件就触发pipeline执行。这个事件可以是你能想到的任何事件。比如手动在界面上触发、其他job主动触发、HTTP API Webhook触发等。
– 由上游任务触发：upstream

有两种方法配置触发器：

(1)在Jenkins Web上配置
(2)写在pipeline中
– 在Jenkins pipeline中使用trigger指令来定义时间触发。tigger指令只能被定义在pipeline块下。
注意：需要手动触发一次任务，让Jenkins加载pipeline后，trigger指令才会生效。

1.1、定时执行：cron

定时执行就像cronjob，到时间就执行。它的使用场景通常是执行一些周期性的job，如每夜构建。
Jenkins trigger cron语法采用的是UNIX cron语法（有些细微的区别）。

一条cron包含5个字段，使用空格或Tab分隔，格式为：MINUTE HOUR DOM MONTH DOW。
每个字段的含义为：
– MINUTE：每小时的第几分钟，取值范围为0∼59。
– HOUR：每天的第几小时，取值范围为0∼23。
– DOM：每月的第几天，取值范围为1∼31。
– MONTH：月份，取值范围为1∼12。
– DOW：每周的第几天，取值范围为0∼7。0和7代表星期天。
还可以使用以下特殊字符，一次性指定多个值。
– *：匹配所有的值
– M-N：匹配M到N之间的值。
– M-N/X or */X：匹配指定范围或整个有效范围，并以X为步长的值。
– A，B，· · ·，Z：使用逗号枚举多个值。

在一些大型组织中，会存在同一时刻执行多个的定时任务的情况，比如每天的零点（0 0 * * *）执行任务，这样会产生负载不均衡。在Jenkins trigger cron语法中使用“H”字符来解决这一问题，H代表hash。（H符号可以被认为是一个范围内的随机值，但它是作业名称的哈希值，而不是一个随机函数，因此该值对于任何给定的项目都保持稳定。）
- 对于没必要准确到零点执行的任务，cron可以这样写：H 0 * * *，代表在0点0分至0点59分之间任何一个时间点执行。
- 需要注意的是，H应用在DOM（一个月的某一天）字段时会有不准确的情况，因为一个月可能是31天，也可能是28天。

Jenkins trigger cron还设计了一些人性化的别名：@yearly、@annually、@monthly、@weekly、@daily、@midnight和@hourly。它们使用哈希值进行自动平衡。

@hourly与H * * * *相同，代表一小时内的任何时间；
@midnight代表在凌晨00:00到02:59之间的某个时间。

#每隔15分钟(可能在:07、:22、:37、:52)
H/15 * * * *
#在每小时的前半个小时每十分钟(三次，可能在:04、:14、:24)
H(0-29)/10 * * * *
#每周一到周五，从09:45到16:45每两个小时执行一次
45 9-16/2 * * 1-5
#每周一到周五，从08:00到15:00每两个小时执行一次（可能在09:38、11:38、13:38、15:38）
H H(8-15)/2 * * 1-5
#除12月外，每月1日和15日每天一次
H H 1,15 1-11 *

在Jenkins Web上配置
已有项目：Jenkins --> My Views --> [项目名称] --> Configure
在pipeline中配置

pipeline {
   	 agent any
   triggers {    //定时触发
        cron('* * * * *')
    }
    stages {
        stage('Hello') {
            steps {
                echo 'Hello World'
            }
        }
    }
}

2.2、轮询代码仓库：pollSCM

轮询代码仓库是指定期到代码仓库询问代码是否有变化，如果有变化就执行。轮询的时间间隔越短越好，因为构建的间隔时间越长，在一次构建内就可能会包含多次代码提交。当构建失败时，你无法马上知道是哪一次代码提交导致了构建失败。
事实上，如果代码有变化，最好的方式是代码仓库主动通知Jenkins，而不是Jenkins频繁去代码仓库检查。那这种方式存在的意义是什么？在一些特殊情况下，比如外网的代码仓库无法调用内网的Jenkins，或者反过来，则会采用这种方式。

Jenkins Web上配置
- 已有项目：Jenkins --> My Views --> [项目名称] --> Configure
在pipeline中配置
- 如果代码仓库http://10.1.1.11:18080/group01/project01-private.git中的dev分支有变化，就会触发该pipeline。

pipeline {
    agent any
    triggers {    //定时扫描代码仓库
        pollSCM('* * * * *')
    }
    stages {
        stage('git-clone') {
            steps {
                git credentialsId: '18729147-da8c-49c5-8573-4bdb05984519', url: 'http://10.1.1.11:18080/group01/project01-private.git', branch: 'dev'
            }
        }
    }
}

2.3、由上游任务触发：upstream

当B任务的执行依赖A任务的执行结果时，A就被称为B的上游任务。在Jenkins 2.22及以上版本中，trigger指令开始支持upstream类型的触发条件。upstream的作用就是能让B pipeline自行决定依赖哪些上游任务。
将upstream定义在下游任务中。这时，当执行上游任务时，就会自动触发下游任务。
当upstreamProjects参数接收多个任务时，使用逗号","分隔。threshold参数是指上游任务的执行结果是什么值时触发，hudson.model.Result是一个枚举，包括以下值：
- ABORTED：任务被手动中止。
- FAILURE：构建失败。
- SUCCESS：构建成功。
- UNSTABLE：存在一些错误，但不至于构建失败。
- NOT_BUILT：在多阶段构建时，前面阶段的问题导致后面阶段无法执行。

在Jenkins Web上配置
- 已有项目：Jenkins --> My Views --> [项目名称] --> Configure
在pipeline中配置
- 执行上游任务test-project-freestyle01或test-project-pipeline02，且其执行状态是成功的，就会触发该pipeline。

pipeline {
    agent any
    triggers {    //由上游任务触发
        upstream(upstreamProjects: 'test-project-freestyle01, test-project-pipeline02', threshold: hudson.model.Result.SUCCESS)
    }
    stages {
        stage('Hello') {
            steps {
                echo 'Hello World'
            }
        }
    }
}

2、GitLab通知触发

GitLab通知触发是指：GitLab发现源代码有变化时，就会触发Jenkins执行构建。
开发推代码触发Jenkins执行构建，如图所示。
由GitLab主动通知进行构建的好处是显而易见的，这样很容易就解决了我们之前提到的轮询代码仓库时“多久轮询一次”的问题，实现每一次代码的变化都对应一次构建。
示例：使用jenkins的test-project-pipeline01项目，Gitlab的http://10.1.1.11:18080/group01/project01-private.git代码仓库。

1、安装GitLab（gitlab-plugin）插件

2、Jenkins：暴露一个webhook

Jenkins --> My Views --> [项目名称] --> Configure
可以看到Jenkins会暴露一个webhook：http://10.1.1.11:18081/project/test-project-pipeline01
- 注意，不论是单分支的pipeline项目还是多分支的pipeline项目，它们暴露的webhook的地址格式都是：/project/＜项目名＞，而不是/job/＜项目名＞。
这个webhook的调用权限取决于以下两个设置项：
- Jenkins全局权限设置。
- 该pipeline是否设置了“Secret token”。
不论Jenkins全局权限如何设置，基于安全的考虑，一般都会为该pipeline生成一个Secret token，只有带上Secret token的请求才会被处理。Secret token 的生成也很简单。只需单击页面上的“Advanced”按钮，就可以看到一个“Secret token”输入框，推荐单击其右下角的“Generate”按钮自动生成Secret token，而不是手动输入。
- 注意。需要保存生成的Secret token，因为在接下来的步骤中会使用到。

3、GitLab：配置通知Jenkins

登录有权限的GitLab用户 --> 点击代码仓库[group01 / project01-private] --> Settings

将Jenkins暴露的webhook和生产的Secret token复制到相应输入框中。
报错：“Url is blocked: Requests to localhost are not allowed”
- 开启webhook功能：使用管理员用户root登录到后台，勾选"Allow requests to the local network from web hooks and services"。

测试整个链路是否通了

在GitLab上添加好这个webhook后，可以跳到表单下方，有一个已添加的webhook列表，找到刚刚创建的webbook。单击“Test”按钮，选择“Push events”，GitLab就会向该webhook发送一个event。
再回到Jenkins上该项目的详情页，在构建历史中，可以看到被GitLab 触发的构建都会被标记为“Started by GitLab push by user02”，这就说明链路已经通了。

4、将构建状态信息推送到GitLab（没有实验成功）

当Jenkins执行完构建后，还可以将构建结果推送到GitLab的相应commit记录上，这样就可以将构建状态与commit关联起来。

创建GitLab Tokens

注意，保持生成的token

创建jenkins凭据
链接GitLab

Jenkins --> Configure System --> [Gitlab]
- 配置好后，单击“Test Connection”按钮，如果返回Success，就说明集成成功了。
- 注意，“Connection name”的值gitlab-token-user01在后面会用到。

(3)在pipeline的post部分，将构建结果更新到GitLab的相应commit记录上。

除此之外，还需要在options部分加入gitLabConnection配置，同时传入“gitlab-token-user01”参数。
- “gitlab-token-user01”参数就是上面的“Connection name”。

pipeline {
    agent any
 
    stages {
        stage('Hello') {
            steps {
                echo 'Hello World'
                error 'hhhhhhhhhhhhhhhhh'
            }
        }
    }
    post {
        success {
            updateGitlabCommitStatus name: 'Hello', state: 'success'
        }
        failure {
            updateGitlabCommitStatus name: 'Hello', state: 'failed'
        }
    }
    options {
      gitLabConnection gitLabConnection: 'gitlab-token-user01', jobCredentialId: ''
    }
}

目录CONTENT

jenkins 构建触发器

1、Jenkins内置触发器

1.1、定时执行：cron

2.2、轮询代码仓库：pollSCM

2.3、由上游任务触发：upstream

2、GitLab通知触发

1、安装GitLab（gitlab-plugin）插件

2、Jenkins：暴露一个webhook

3、GitLab：配置通知Jenkins

4、将构建状态信息推送到GitLab（没有实验成功）

评论区