当前位置：首页 > news >正文

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

news 2025/11/6 7:30:44

在这里插入图片描述

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 部分

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 字段解释：

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，否则就毫无意义了。