众所周知,配置 pipeline 需要在项目中配置一个 Jenkinsfile 文件,存放 pipeline 脚本 (不考虑 job 中直接写脚本的方式,维护起来太繁琐)。
我猜这个设计的初衷应该是让开发人员能自己维护 Jenkinsfile,但是对于多数互联网公司而言,这个环节一般是 qa 团队在维护。当 Jenkinsfile 散落在多个项目中时,维护起来也是一件麻烦事。有没有办法将 Jenkinsfile 都集中管理起来呢?
前段时间在知乎上看到一篇技术专栏,作者@pulord
借助pipeline-multibranch-defaults
插件巧妙的实现了 Jenkinsfile 和项目代码的分离。兴奋之余,赶紧尝试了一番,也在项目中实践了起来。在此分享一下使用过程和踩坑记录。
workflow-multibranch
插件是一个能扫描项目分支、自动生成分支流水线 job 的插件,使用起来十分便利。
而pipeline-multibranch-defaults
插件正是由它修改而来,该插件作者在workflow-multibranch
插件的基础上增加了 Default Jenkinfile 的功能。
简单来说,该插件除了能自动创建多分支的 job 以外,还能给这些 job 指定一个默认的 Jenkinsfile,该 Jenkinsfile 可以配置在 Jenkins 中,无需在项目代码中配置。
1.插件详细介绍 (原作者) 、 2.插件地址 (Jenkins 官方库)
@pulord
使用的方法比较巧妙,详细过程可以参看原文👉:Jenkins-Pipeline 实践浅谈
大致流程如下:
按照以下目录结构存放 Jenkinsfile:
#例:
--项目名称1
-分支1
-Jenkinsfile
-分支2
-Jenkinsfile
--app_server
-master
-Jenkinsfile
-dev
-Jenkinsfile
# 备注:Jenkinsfile中就是各个项目/分支真正的流水线脚本,比如一个完整的声明式pipeline。
脚本内容如下:
#!/usr/bin/env groovy
import groovy.transform.Field
@Field def job_name=""
node()
{
// 获取当前job名称。也可以按需自定义
job_name="${env.JOB_NAME}".replace('%2F', '/').split('/')
job_name=job_name[0]
// 自定义workspace
workspace="/data/jenkins/workspace/CI"
ws("$workspace")
{
dir("pipeline")
{
// clone Jenkinsfile项目
git url: 'git@XXYY.com:pipeline.git'
// 根据job name、构建分支,自动加载对应的Jenkinsfile
def check_groovy_file="${job_name}/${env.BRANCH_NAME}/Jenkinsfile"
load "${check_groovy_file}"
}
}
}
// 该脚本的作用:clone包含所有Jenkinsfile的代码库,根据项目名称load对应的Jenkinsfile.
// 与原作者有一点出入,我没有在自己的Jenkinsfile中定义start()函数,所以此处删去了调用。load之后便会自动执行pipeline脚本。个人猜测,原作者的Jenkinsfile采用脚本化语法
by default Jenkinsfile
,输入步骤 2 中的 script ID。1. Multibranch job 自定义构建的分支
使用该插件部署的 job,默认会为所有分支创建单独的 job。如果分支过多简直是噩梦...
想要指定构建的分支也很简单,只需在 “行为” 配置项中新增一个 “根据名称过滤”,然后写正则表达式即可。
2. Jenkinsfile 中 load 自定义函数
作者的举例中有自定义一个common_util.grroovy
函数库。在 Jenkinsfile 中使用该函数库时,不能以它们的真实路径 load。
因为 Jenkinsfile 已经被 Default-Jenkinsfile 加载到了项目根目录,所以应该以项目根目录为起点,再去 load common_util.groovy
。
3. 快速校验 pipeline 语法
编写声明式脚本时,总会遇到一些语法问题(官方文档也烂)。为了快速调试语法规范性,可以借助一款 vscode 插件---Jenkins Pipeline Linter Connector
,实现一键校验脚本语法。
Jenkins 官网有提及,详细使用可以参看插件作者介绍:插件地址。
该插件的工作原理就是利用 Jenkins 的接口校验脚本的语法规范性。
4. 调试技巧
由于 Jenkins 服务器不在本地,每次调试都要先 push 代码,再执行 job。不仅效率低,还会导致一些垃圾 commit。
为了省事,换了一种思路:
就是用 docker 在本地搭一个 Jenkins 环境 (当然,如果 Jenkins 环境就在本地再好不过了。在此顺便夸一下 docker 的便利性🙂),然后把 Default Jenkinsfile 中 clone pipeline 操作注释掉,直接在 workspace 目录下修改脚本,这样就省去了 commit 步骤。
(虽然方法粗暴,可是当时的瓜脑袋一直没想到,直到 push 了 30 多次才反应过来...)
5. 配置 webhook
使用Generic Webhook Trigger
插件即可。
不过关于它的使用,估计又能写一篇....🤦