基于 Kickstart 的 Linux OS CICD 部署(webhook)

Author：Arsen

Date：2025/11/05

背景

之前写了一篇 OS 自动化安装的文章《基于 IPMI + Kickstart + Jenkins 的 OS 自动化安装》，并没有给出具体的 Pipeline 流水线脚本，因为这些脚本实际上编写是灵活的，重点是要具备 Pipeline 的基础语法和 Linux OS 部署的整体思路。

而我的 Pipeline 流水线脚本是通过 gitlab 进行版本控制的，但熟悉 Jenkins 构建流程的朋友应该会发现，你每次的 Pipeline 流水线脚本更新后的提交，并不会实时在 Jenkins 端进行相应，比如 Pipeline 流水线脚本新增某个菜单控件或其他选项参数，都需要手动到 Jenkins 触发一次才会更新，才会显示你所添加的菜单控件或其他选项参数，这其实是比较麻烦的。

这时就需要使用到 Jenkins 和 Gitlab 的 webhook 功能，其实这个功能我早在三四年前也发布过 webhook 相关的文章。那 webhook 是什么？有什么用？通俗地讲它叫"钩子"，如果你的 Pipeline 流水线作业进行了 Gitlab 版本控制，且 Jenkins 和 Gitlab 配置了 webhook，就可实现 Pipeline 流水线脚本的分支推送后 Jenkins 构建界面的实时更新。

但并不是所有项目都推荐使用 webhook，要根据实际情况选择性使用，建议你使用 webhook 时，Pipeline 流水线脚本最好是加上一些构建开关，避免误操作自动构建后目标 OS 发生异常。

所以，本次的目标：Gitlab 管理的 Pipeline 流水线脚本更新且推送后，实现 Jenkins 实时更新。

环境

硬件：

1台 x86/aarch64 16C/64G 硬件服务器，用于部署 CICD 环境。

软件：

Jenkins/2.440.3，Generic Webhook Trigger 插件

Gitlab/15.11.2

配置

Pipeline

在 Jenkins 的 Pipeline 流水线脚本中新增 triggers 自动触发配置，注意需要 Jenkins 提前安装 Generic Webhook Trigger 插件。

重点关注：token 和 regexpFilterExpression 部分

sh 复制代码

pipeline {
    agent any
    // 自动触发配置
    triggers {
        GenericTrigger(
            genericVariables: [
                [key: 'ref', value: '$.ref'],
                [key: 'commit_message', value: '$.commits[0].message'],
                [key: 'author', value: '$.commits[0].author.name']
            ],
            causeString: 'GitLab webhook triggered by $ref',
            token: 'jenkins-gitlab-token-devops',
            printContributedVariables: false,
            printPostContent: false,
            regexpFilterText: '$ref',
            regexpFilterExpression: 'refs/heads/(main|v1.0.1)'
        )
    }
    // 全局参数
    parameters {
        ...
    }
    stages {
        stage('OS_init') {
            ...
        }
        stage('OS_grub') {
            ...
        }
        stage('OS_install') {
        	...
        }
        ...
    }
}

triggers 字段解释：

sh 复制代码

1.genericVariables - 提取 GitLab Webhook 数据
作用：从 GitLab 的 JSON payload 中提取变量
JSON路径说明：
$.ref → GitLab 推送的引用路径，如：refs/heads/main
$.commits[0].message → 第一个提交的提交信息
$.commits[0].author.name → 提交者姓名
可用变量：在流水线中通过 env.ref, env.commit_message, env.author 访问

2.causeString - 构建原因描述
作用：显示在 Jenkins 构建历史中的触发原因
causeString: 'GitLab webhook triggered by $ref' → $ref 会被替换为实际的引用路径

3.token - 安全令牌
作用：安全验证，确保只有合法的 GitLab 可以触发
要求：GitLab Webhook 中必须配置相同的 token
token: 'jenkins-gitlab-token-devops'

4.printContributedVariables - 调试信息
作用：是否在构建日志中打印提取的变量值
printContributedVariables: false → true：开发调试时使用,false：生产环境建议关闭，避免敏感信息泄露

5.printPostContent - 请求内容打印
作用：是否打印完整的 Webhook 请求内容 → true：调试时查看完整的 JSON payload,false：生产环境建议关闭

6.regexpFilterText - 过滤文本
作用：指定用于正则过滤的变量
regexpFilterText: '$ref' → 使用 $ref 变量（分支引用路径）进行过滤

7.regexpFilterExpression - 正则表达式
作用：只有匹配该正则表达式时才触发构建
regexpFilterExpression: 'refs/heads/(main|v1.0.1)' → 只监听 main 和 v1.0.1 分支的推送

配置完成后，Jenkins 手动构建一次，使 triggers 生效，便于获取 webhook URL，如下图：

该 URL（http://JENKINS_URL/generic-webhook-trigger/invoke）用于后续 Gitlab 的"钩子"配置。

Gitlab Webhook

首先确认 Jenkins 的 Pipeline 流水线脚本 Git 版本仓库，如下图：

再次确认控制的版本号，如下图：

确认后，到 Gitlab web 端进行 webhook 配置，具体步骤如下：

找到控制的 Git 仓库后，点击 Settings => Webhooks

将 3.1 部分获取到的 RUL、Pipeline 配置的 token 正确填写到对应部分，RUL 的 IP 就是 Jenkins 的 IP

然后点击 "Add webhook"，随后即可添加成功，如下图：

接着点击 "Test => Push events"看是否可用：

如下图返回 "200" 状态码说明该 webhook 可用：

这里要注意的是，为什么一定要在这个 Git 仓库下配置 webhook，在其他仓库难道不行吗？其实你在哪个 Git 仓库配置无所谓，都能触发 Jenkins 对应作业的自动构建效果，只是因为 Jenkins 作业用到了 Git 上的这个仓库，我们才会在这个仓库创建 webhook，否则就毫无意义了。

验证

Pipeline 流水线脚本更新：新增一个 webhook 测试控件

新增完成后推送到 Git 仓库的 v1.0.1 分支：

然后登录 jenkins web 端查看是否自动触发构建，如下图，已正常自动触发构建了，因为我们前面 pipeline 配置的就是 main 或 v1.0.1 分支，所以当这两个分支只要有提交就会触发 webhook：

自此，基于 Kickstart 的 Linux OS CICD 部署(webhook)验证完毕，本次没有演示 OS 部署，因为我之前的文章《基于 IPMI + Kickstart + Jenkins 的 OS 自动化安装》已经验证过了，大家可以结合在一起看。

基于 Kickstart 的 Linux OS CICD 部署(webhook)

目录

背景

环境

配置

Pipeline

Gitlab Webhook

验证