目 录CONTENT

文章目录

jenkins 构建触发器

Seven
2024-03-07 / 0 评论 / 0 点赞 / 328 阅读 / 11248 字 / 正在检测是否收录...
  • Jenkins自动化是指项目按照一定的规则自动执行,这些规则被称为项目触发条件。
  • Jenkins内置支持cron、pollSCM、upstream三种方式。其他方式可以通过插件来实现。

1、Jenkins内置触发器

  1. 对于触发条件,可以从两个维度来区分:时间触发和事件触发。
  • 时间触发是指定义一个时间,时间到了就会触发项目执行。
    – 定时执行:cron
    – 轮询代码仓库:pollSCM
  • 事件触发就是发生了某个事件就触发pipeline执行。这个事件可以是你能想到的任何事件。比如手动在界面上触发、其他job主动触发、HTTP API Webhook触发等。
    – 由上游任务触发:upstream
  1. 有两种方法配置触发器:
  • (1)在Jenkins Web上配置
  • (2)写在pipeline中
    在Jenkins pipeline中使用trigger指令来定义时间触发。tigger指令只能被定义在pipeline块下。
    注意:需要手动触发一次任务,让Jenkins加载pipeline后,trigger指令才会生效。

1.1、定时执行:cron

  1. 定时执行就像cronjob,到时间就执行。它的使用场景通常是执行一些周期性的job,如每夜构建。
  2. 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:使用逗号枚举多个值。
  1. 在一些大型组织中,会存在同一时刻执行多个的定时任务的情况,比如每天的零点(0 0 * * *)执行任务,这样会产生负载不均衡。在Jenkins trigger cron语法中使用“H”字符来解决这一问题,H代表hash。(H符号可以被认为是一个范围内的随机值,但它是作业名称的哈希值,而不是一个随机函数,因此该值对于任何给定的项目都保持稳定。)

    • 对于没必要准确到零点执行的任务,cron可以这样写:H 0 * * *,代表在0点0分至0点59分之间任何一个时间点执行
    • 需要注意的是,H应用在DOM(一个月的某一天)字段时会有不准确的情况,因为一个月可能是31天,也可能是28天。
  2. 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 *
    
  3. 在Jenkins Web上配置
    已有项目:Jenkins --> My Views --> [项目名称] --> Configure
    image

  4. 在pipeline中配置

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

2.2、轮询代码仓库:pollSCM

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

    • 已有项目:Jenkins --> My Views --> [项目名称] --> Configure
      image-1709778761986
  2. 在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:在多阶段构建时,前面阶段的问题导致后面阶段无法执行。
  1. 在Jenkins Web上配置

    • 已有项目:Jenkins --> My Views --> [项目名称] --> Configure
      image-1709778938878
  2. 在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执行构建,如图所示。
    image-1709779151930

  • 由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
    image-1709779253726
  • 可以看到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,因为在接下来的步骤中会使用到。
      image-1709780634805

3、GitLab:配置通知Jenkins

  1. 登录有权限的GitLab用户 --> 点击代码仓库[group01 / project01-private] --> Settings
  • 将Jenkins暴露的webhook和生产的Secret token复制到相应输入框中。
    image-1709780734586
  • 报错:“Url is blocked: Requests to localhost are not allowed”
    • 开启webhook功能:使用管理员用户root登录到后台,勾选"Allow requests to the local network from web hooks and services"。
      image-1709780845592
  1. 测试整个链路是否通了
  • 在GitLab上添加好这个webhook后,可以跳到表单下方,有一个已添加的webhook列表,找到刚刚创建的webbook。单击“Test”按钮,选择“Push events”,GitLab就会向该webhook发送一个event。
  • 再回到Jenkins上该项目的详情页,在构建历史中,可以看到被GitLab 触发的构建都会被标记为“Started by GitLab push by user02”,这就说明链路已经通了。
    image-1709781021265

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

  • 当Jenkins执行完构建后,还可以将构建结果推送到GitLab的相应commit记录上,这样就可以将构建状态与commit关联起来。
  1. 创建GitLab Tokens
  • 注意,保持生成的token
    image-1709781079382
  1. 创建jenkins凭据
    image-1709781712906
  2. 链接GitLab
  • Jenkins --> Configure System --> [Gitlab]
    • 配置好后,单击“Test Connection”按钮,如果返回Success,就说明集成成功了。
    • 注意,“Connection name”的值gitlab-token-user01在后面会用到。
      image-1709781764631
  1. (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: ''
    }
}
0

评论区