Ci on Liangweidong's blog

Jenkins 镜像实战：JDK21 升级、Agent 集群、钉钉/企微通知、Kubernetes 动态 Agent 与流水线部署 Java/Golang/Vue

Sun, 15 Sep 2024 00:00:00 +0800

Jenkins 是 CI/CD 界的"老大哥"——2004 年从 Hudson 分支出来后，已经走了 20 年。2024 年 9 月它发布了基于 JDK21 的 LTS（2.504.x 系列），而 2024-09-24 正是 Jenkins 官方对 JDK11 镜像停止安全更新的日期。这篇文章不是"Jenkins 是什么"的科普文，而是把零散的实战笔记整理成"从镜像拉取到一条完整流水线"的路径：拉哪个镜像、Agent 怎么挂、钉钉/企微通知怎么接、Kubernetes 上的动态 Agent 怎么配、流水线部署 Java/Golang/Vue 项目分别怎么写。

阅读对象：需要从零搭一套 Jenkins CI/CD，或正在做 JDK8→JDK11→JDK21 升级的开发者、运维
覆盖范围：官方 LTS 镜像选择、Agent 节点（JNLP）、钉钉/企业微信 webhook 通知、Active Choices 级联参数、Generic Webhook Trigger 触发、SSH/Credentials 凭据、Kubernetes 动态 Agent（jnlp-slave）、自定义 sshpass/rsync Agent、流水线部署 Java/Golang/Vue 模板、常见排错

一、Jenkins 镜像选择：JDK8 / JDK11 / JDK21 LTS

Jenkins 官方镜像 jenkins/jenkins 有几个常用 tag，先把它们的关系理清楚：

Tag	含义	备注
`2.346.3-lts-jdk8`	JDK8 + Jenkins 2.346.3 LTS	2022 年主流选择，但 JDK8 已停止安全更新
`2.440.3-lts-jdk11`	JDK11 + Jenkins 2.440.3 LTS	2024 年过渡选择，2024-09-24 停止安全更新
`2.504.2-lts-jdk21`	JDK21 + Jenkins 2.504.2 LTS	当前推荐（LTS 路线）

When to use：JDK21 LTS（2.504.x 系列）已是新装 Jenkins 的默认推荐。JDK11 LTS 在 2024-09-24 之后不再收安全补丁——还在跑 JDK11 的同学需要规划升级。

1.1 最小启动：JDK8 老镜像

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 拉镜像
docker pull jenkins/jenkins:2.346.3-lts-jdk8

# 创建数据目录
mkdir -p /data/jenkins/home
chown -R 1000:1000 /data/jenkins/home

# 启动
docker run --name jenkins -d \
 -p 8090:8080 \
 -p 50000:50000 \
 -v /data/jenkins/apache-maven-3.8.6:/data/jenkins/apache-maven-3.8.6 \
 -v /data/jenkins/.nvm:/data/jenkins/.nvm \
 -v /data/jenkins/home:/var/jenkins_home \
 -v /etc/localtime:/etc/localtime \
 --restart=on-failure \
 jenkins/jenkins:2.346.3-lts-jdk8

坑 1：第一个启动慢是因为它要执行 init.groovy.d 下的初始化脚本，并下载默认插件。耐心等几分钟，初始密码可以通过 docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword 拿到。

1.2 JDK11 升级路径（已被 JDK21 取代）

如果已经在线上跑着 JDK8 或 JDK11，可以保留数据卷 jenkins_home，直接换镜像 tag 升级。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# docker-compose.yaml
version: '3'
services:
 jenkins:
 image: jenkins/jenkins:2.440.3-lts-jdk11
 container_name: jenkins11
 restart: always
 privileged: true
 environment:
 - TZ=Asia/Shanghai
 - JAVA_OPTS=-Duser.timezone=Asia/Shanghai
 ports:
 - "8091:8080"
 - "50001:50000"
 volumes:
 - "/var/run/docker.sock:/var/run/docker.sock" # 让 Jenkins 在容器内调 docker
 - "/usr/bin/docker:/usr/bin/docker"
 - "/home/docker/jenkins11/work:/var/jenkins_home"
 - "/usr/local/maven/apache-maven-3.9.3:/usr/local/maven/apache-maven-3.9.3"
 - "/etc/localtime:/etc/localtime:ro"

升级完后第一次启动会提示"java11 将在 2024-09-24 结束支持"——这是 Jenkins 内置的提示，不是 bug。

坑 2：挂 docker.sock 是为了在 Jenkins 容器内构建镜像（docker build）。但这等同于把宿主机的 docker 权限交给 Jenkins，多用户场景需要谨慎。

1.3 JDK21 升级路径（当前推荐）

1
2
3


docker pull jenkins/jenkins:2.504.2-lts-jdk21
docker tag jenkins/jenkins:2.504.2-lts-jdk21 <private-registry>/base/jenkins/jenkins:2.504.2-lts-jdk21
docker push <private-registry>/base/jenkins/jenkins:2.504.2-lts-jdk21

把启动脚本里的镜像 tag 换成 2.504.2-lts-jdk21 即可，数据卷 jenkins_home 完全兼容——Jenkins 2.504.x 会自动迁移配置。

坑 3：容器时区是对的，但 Jenkins 日志时间格式仍是 UTC。解决：在 系统管理 → 脚本命令行 执行 System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone', 'Asia/Shanghai')，或启动时加 -e JAVA_OPTS=-Duser.timezone=Asia/Shanghai。新版本还支持在 用户列表 → admin → 设置 → 用户自定义时区 里改 UI 时区，但日志里那行仍是 UTC。

二、必备插件清单

Jenkins 的 90% 价值在插件。一份覆盖 90% 场景的最小集合：

插件	作用
`git` / `gitlab`	Git 源码拉取、GitLab 集成
`SSH plugin`	SSH 远程执行命令
`Publish Over SSH`	把构建产物 SCP 到远端并执行命令
`SSH Pipeline Steps` (`ssh-steps`)	流水线里用 `sshCommand` / `sshPut`
`Maven Integration`	构建 Maven 项目
`NodeJS`	构建 Node 项目
`Go`	构建 Golang 项目
`git-parameter`	构建时选择 Git 分支
`Active Choices` (`uno-choice`)	多级参数级联
`Generic Webhook Trigger`	接收 Git 服务的 webhook
`Qy Wechat Notification`	构建后发企业微信
`DingTalk`	构建后发钉钉
`Naginator`	构建失败后自动重试
`Environment Injector`	注入运行时环境变量
`Pipeline` / `Workflow Aggregator`	流水线基础
`Kubernetes`	在 K8s 上跑动态 Agent
`JDK Parameter`	多 JDK 项目里选择 jdk 版本
`Config File Provider`	集中管理 `settings.xml` / `npmrc` 等配置文件

坑 4：插件安装慢？Jenkins 4.x 之后插件源会从 updates.jenkins-ci.org 拉。国内网络下经常卡死，建议：

用 *.hpi 文件手动下载：https://updates.jenkins-ci.org/download/plugins/

或在 系统管理 → 插件管理 → 高级 里把 升级站点 换成国内镜像（如 https://mirror.tuna.tsinghua.edu.cn/jenkins/updates/）

三、钉钉 / 企业微信通知：3 行就能接

3.1 钉钉机器人

群设置 → 智能群助手 → 添加机器人 → 自定义
安全设置选"自定义关键词"或"加签"
拿到 webhook（形如 https://oapi.dingtalk.com/robot/send?access_token=xxxx）
Jenkins 安装 DingTalk 插件，在 Job 配置里填 webhook

curl 直接测试：

1
2
3


curl 'https://oapi.dingtalk.com/robot/send?access_token=<YOUR_TOKEN>' \
 -H 'Content-Type: application/json' \
 -d '{"msgtype":"markdown","markdown":{"title":"构建通知","text":"## ${JOB_NAME} 构建成功"}}'

3.2 企业微信机器人

群右键 → 群机器人 → 添加 → 选"群机器人"
拿到 webhook（形如 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx）
Jenkins 安装 Qy Wechat Notification 插件

1
2
3
4
5
6
7
8


curl "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=<YOUR_KEY>" \
 -H "Content-Type: application/json" \
 -d '{
 "msgtype": "markdown",
 "markdown": {
 "content": "## ${JOB_NAME} 构建信息\n**构建ID**: ${BUILD_ID}\n**状态**: ${currentBuild.currentResult}\n[查看日志](${BUILD_URL}/console)"
 }
 }'

3.3 在 Pipeline 里推 commit 信息

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


sh '''
 git config --global log.date format:'%Y-%m-%d %H:%M:%S'
 commit_info=$(git log -1 --oneline --pretty=format:'%s by %an at %cd' --no-merges)
'''
def commitInfo = sh(script: "git log -1 --oneline --pretty=format:'%s by %an at %cd' --no-merges", returnStdout: true).trim()

httpRequest(
 url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=<YOUR_KEY>',
 httpMode: 'POST',
 contentType: 'APPLICATION_JSON',
 requestBody: """
 {"msgtype":"markdown","markdown":{"content":"<font color=\"warning\">**${env.JOB_NAME} 构建**</font>\n>提交：${commitInfo}\n>状态：${currentBuild.currentResult}\n[日志](${env.BUILD_URL}/console)"}}
 """
)

坑 5：把 webhook 凭据硬编码在脚本里？不要这样做。把 webhook 放进 Jenkins 凭据（Credentials）→ Secret text 里，再通过 withCredentials([string(credentialsId: 'wechat-webhook', variable: 'WEBHOOK')]) 引用。

四、Agent 集群：JNLP 节点 + K8s 动态 Agent

4.1 JNLP Agent（传统固定节点）

适合：物理机 / 虚拟机 / 容器化的固定 Agent。

前置：在 Agent 机器上装好 java、maven、git。

启动方式 A：java web 启动代理

1
2
3
4
5


nohup java -jar /usr/local/jenkins/agent.jar \
 -jnlpUrl http://<JENKINS_URL>/computer/<NODE_NAME>/jenkins-agent.jnlp \
 -secret <SECRET_FROM_JENKINS> \
 -workDir "/usr/local/jenkins/ws" \
 > nohup.log &

启动方式 B：Kubernetes 上的 JNLP 静态 Agent

1
2


# jenkins-master 上的 SSH remote hosts / Publish over SSH
# 用 Publish Over SSH 把 jar 推到远端, 然后 java -jar 启动

4.2 Kubernetes 动态 Agent（推荐）

Jenkins 装 Kubernetes 插件，每次 Job 触发时在 K8s 里拉一个临时 Pod，构建完销毁。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


pipeline {
 agent {
 kubernetes {
 cloud 'k8s' # 配在 系统管理 → 节点管理 → Configure Clouds
 inheritFrom 'jnlp-slave' # 复用 Pod Template
 namespace 'kube-ops'
 }
 }
 stages {
 stage('build') {
 steps {
 container('jnlp') {
 sh 'mvn clean package -P prod'
 }
 }
 }
 }
}

前置：

制作 Jenkins 连接 K8s 的证书（K8s ~/.kube/config 的 certificate-authority-data / client-certificate-data / client-key-data 三个字段，base64 解码后保存）
把 kube-ca.crt + kube-cert.pfx 配到 Jenkins 凭据里
创建一个 jnlp-slave Pod Template（基础镜像 jenkins/inbound-agent:latest-jdk21）

K8s 集群配置：

1
2


Kubernetes Cloud URL: https://<K8S_API_SERVER>:6443
Kubernetes Cloud Credentials: <上面做的 pfx 凭据>

坑 6：Pod 启动失败？用 kubectl logs -f --tail=10 查看 Jenkins 动态创建的 Pod。80% 的情况是 jnlp-slave Pod Template 里的镜像拉不到（私有仓库没配 imagePullSecrets）或 Jenkins 容器内没装 rsync。

4.3 自定义 Agent 镜像（装 rsync + sshpass）

jenkins/inbound-agent 基础镜像不带 rsync 和 sshpass，但流水线里经常要用。两种方式：

方式 A：临时容器安装 + commit

1
2
3
4
5
6
7
8


docker run -u root -it --name jenkins-agent-temp \
 jenkins/inbound-agent:latest-jdk21 /bin/bash
# 容器内
apt update && apt install -y rsync sshpass
exit
# 宿主机
docker commit jenkins-agent-temp <private-registry>/base/jenkins/inbound-agent:latest-jdk21-rsync
docker push <private-registry>/base/jenkins/inbound-agent:latest-jdk21-rsync

方式 B：Dockerfile（推荐，可追溯）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


ARG version=latest-jdk21
FROM jenkins/inbound-agent:$version
ARG version
LABEL Description="Custom Jenkins Agent with rsync and sshpass" Vendor="某安全公司" Version="$version"
ARG user=jenkins
USER root
RUN apt-get update && \
 apt-get install -y rsync sshpass && \
 rm -rf /var/lib/apt/lists/*
USER ${user}
ENTRYPOINT ["/usr/local/bin/jenkins-agent"]

1
2


docker build -t <private-registry>/base/jenkins/inbound-agent:latest-jdk21-rsync .
docker push <private-registry>/base/jenkins/inbound-agent:latest-jdk21-rsync

五、流水线：声明式 vs 脚本式

5.1 声明式（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


pipeline {
 agent any
 options {
 buildDiscarder logRotator(daysToKeepStr: '10', numToKeepStr: '10')
 timeout(time: 30, unit: 'MINUTES')
 }
 parameters {
 choice(name: 'profiles', choices: ['dev', 'test', 'prod'], description: '请选择构建环境')
 }
 triggers {
 GenericTrigger(
 genericRequestVariables: [[key: 'profile', regexpFilter: '$']],
 token: 'test'
 )
 }
 stages {
 stage('git checkout') {
 steps {
 git branch: 'master', credentialsId: 'gitlab-cred', url: 'http://<GITLAB>/<your-org>/gdsTmqtt.git'
 }
 }
 stage('build') {
 steps {
 sh 'mvn clean package -P prod -DskipTests'
 }
 }
 stage('publish') {
 steps {
 sshPublisher(
 publishers: [sshPublisherDesc(
 configName: 'prod-server',
 transfers: [sshTransfer(
 cleanRemote: false,
 execCommand: '''
 mkdir -p /home/project/safety/gdsTmq/jar
 docker rm -f gdsTomq
 mv /home/tmp/safety-gdsTomq/*.jar /home/project/safety/gdsTmq/jar/
 docker run -d --restart=always --net=host --name=gdsTomq \
 -v /home/project/safety/gdsTmq/jar:/jar \
 <private-registry>/base/jdk:8u381-2 \
 java -jar /jar/gds-0.0.1-SNAPSHOT.jar
 ''',
 remoteDirectory: '/home/tmp/safety-gdsTomq',
 sourceFiles: 'target/gds-0.0.1-SNAPSHOT.jar'
 )]
 )]
 )
 }
 }
 }
 post {
 success { echo 'deploy success' }
 failure { echo 'deploy failed' }
 }
}

5.2 脚本式（灵活但难维护）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


node {
 stage('Remote SSH') {
 def remote = [:]
 remote.name = 'test'
 remote.host = '<INTERNAL_HOST>'
 remote.user = 'root'
 remote.password = '<REDACTED>'
 remote.allowAnyHosts = true
 sshCommand remote: remote, command: "ls -lrt"
 }
}

坑 7：声明式是 2017 年之后的官方推荐。新项目用声明式；老项目如果是脚本式，不要一次性重写，逐步迁移。

六、Active Choices：多级参数级联

真实场景：先选节点（master/dev/联创），再选项目（不同节点不同项目），再选主机（不同节点不同主机），再选分支（不同项目不同分支）。

步骤：

Job 选"参数化构建"
加 Active Choices Parameter，name=agent，Choice Type=Single
Script：

1

return ["master", "dev", "liangchuang"]

加 Active Choices Reactive Parameter，name=project，Referenced parameters=agent

1
2
3
4
5


if (agent.equals("master")) {
 return ["safetyBackend", "safetyAppBackend", "safetyFrontend", "safetyAuth", "safetyAppH5", "safetyGds"]
} else if (agent.equals("dev")) {
 return ["safetyBackend", "safetyAuth"]
}

同样做 host（referenced=agent）、branch（referenced=project）

坑 8：低版本 Jenkins（2.346.x）装 Active Choices 时提示依赖缺失，要先装 script-security 1.x 版本，再装 uno-choice。

七、流水线部署三类项目：Java / Golang / Vue

7.1 部署 Java 项目

参考第五章 5.1 的完整 pipeline。核心点：

mvn clean package -P <profile> 打 jar
sshPublisher 把 jar 传到目标机器
远端 docker rm -f <container> + docker run -d 重启

钉钉/企微通知 + commit 信息：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


stage('notify') {
 steps {
 sh '''
 git config --global log.date format:'%Y-%m-%d %H:%M:%S'
 commit_info=$(git log -1 --oneline --pretty=format:'%s by %an at %cd' --no-merges)
 '''
 script {
 def commitInfo = sh(script: "git log -1 --oneline --pretty=format:'%s by %an at %cd' --no-merges", returnStdout: true).trim()
 httpRequest(
 url: "<WEBHOOK_URL>",
 httpMode: 'POST',
 contentType: 'APPLICATION_JSON',
 requestBody: "{\"msgtype\":\"markdown\",\"markdown\":{\"content\":\"**${env.JOB_NAME} 构建成功**\\n>提交：${commitInfo}\"}}"
 )
 }
 }
}

7.2 部署 Golang 项目

Golang 项目的特殊点：Go 安装路径、GOPATH 设置、交叉编译。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


pipeline {
 agent any
 environment {
 GOPATH = "${JENKINS_HOME}/golang_workspace"
 GOPROXY = "https://goproxy.cn"
 }
 stages {
 stage('build') {
 steps {
 sh '''
 export PATH=$PATH:$GOPATH/bin
 mkdir -p $GOPATH
 CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o main main.go
 '''
 }
 }
 stage('publish') {
 steps {
 sshCommand remote: [...], command: '''
 rm -f /home/project/tailings/main
 mv /home/docker/jenkins/data/workspace/tailings-backend/main /home/project/tailings/
 chmod +x /home/project/tailings/main
 docker-compose -f /home/docker-compose.yml restart tailings-backend
 '''
 }
 }
 }
}

坑 9：Jenkins 装 Go 插件后，Go 路径会被装到 $JENKINS_HOME/tools/org.jenkinsci.plugins.golang.GolangInstallation/go/<version>/。如果手动 tar -C 解压到 /home/docker/jenkins/data/go/，路径对不上会找不到——解决方法是用 tar -C 时直接建 go1.21.5 子目录，让最终路径是 /home/docker/jenkins/data/go/go1.21.5/。

7.3 部署 Vue 项目

Vue 项目用 npm 构建，产物在 dist/：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


pipeline {
 agent any
 tools {
 nodejs 'node14.17.3' # 在 全局工具配置 里先加 NodeJS 安装
 }
 stages {
 stage('build') {
 steps {
 sh '''
 npx browserslist@latest --update-db
 npm install
 npm run build:test
 cd dist
 tar -zcvf dist.tar.gz *
 '''
 }
 }
 stage('publish') {
 steps {
 sshPublisher(
 publishers: [sshPublisherDesc(
 configName: 'frontend-server',
 transfers: [sshTransfer(
 sourceFiles: 'dist/dist.tar.gz',
 removePrefix: 'dist/',
 remoteDirectory: '/project/frontend/dist',
 execCommand: '''
 cd /home/project/frontend/dist
 shopt -s extglob
 rm -rf !(dist.tar.gz)
 tar -zxvf dist.tar.gz -C ./
 rm -rf dist.tar.gz
 cd /home
 docker-compose restart frontend
 '''
 )]
 )]
 )
 }
 }
 }
}

坑 10：docker-compose restart frontend 只重启容器，不会重新读 docker-compose.yaml 的端口/环境变量。改了 compose 文件必须 docker-compose up -d。

八、定时构建 + 自动合并代码

轮询 SCM（在 Job 的"构建触发器"里勾选"轮询 SCM"）：

1
2
3
4
5


TZ=Asia/Shanghai
0 9,13 * * * # 每天 9 点和 13 点
0 14,20 * * * # 每天 14 点和 20 点
*/5 16-17 * * * # 每天 16-17 点，每 5 分钟
H/5 * * * * # 每 5 分钟（H 是 hash 分散）

坑 11：5 个星分别是"分时日月周"，别写反。H/5 比 */5 好——Jenkins 会在集群内做 hash 分散，多个 Job 不会同时触发。

自动合并代码（在 SCM 的 Additional Behaviours 加）：

Clean before checkout（构建前清空工作区）
Prune stale remote-tracking branches（同步远程分支）
Merge before build（构建前 merge 目标分支）

坑 12：Name of repository 一定要写 origin，否则 Merge before build 报 Could not find remote ref。

九、常见排错

9.1 “Waiting for Jenkins to finish collecting data” 等待时间长

Jenkins 通过 Maven 构建 Java 项目后，会做 指纹验证——给每个 jar 算一个 SHA-1，写入数据库。Java 项目越大、依赖越多，等待时间越长。

解决：关掉指纹验证 → Job 配置 → 构建环境 → 勾选 “Disable deferred wipeout and improve performance”。

9.2 中文乱码

启动加：

1
2


LANG=zh_CN.UTF-8
JAVA_OPTS=-Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8 -Duser.timezone=Asia/Shanghai

9.3 IllegalArgumentException: No enum constant io.jenkins.plugins.localization_zh_cn.UserCommunityProperty.ShowConditions

中文插件版本不兼容。解决：删除中文插件 → 重装匹配 Jenkins 版本的 localization-zh-cn 插件 → 重启。

9.4 Publish Over SSH 连接超时

检查：

~/.ssh/known_hosts 里有没有目标机器的公钥（StrictHostKeyChecking=no 可绕过）
远端 sshd_config 是否允许 PasswordAuthentication yes
网络是否可达（telnet <INTERNAL_HOST> 22）

9.5 流水线里 Git 拉取失败

1
2
3
4
5


git branch: 'master', 
 credentialsId: 'gitlab-cred', 
 url: 'http://<INTERNAL_HOST>:13000/<your-org>/gdsTmqtt.git',
 // 新版要加 poll: false 否则每分钟检查一次
 poll: false

9.6 Kubernetes 插件连接集群失败

1
2
3
4


# 查看 Jenkins 创建的 agent pod 日志
kubectl logs -f --tail=10 \
 $(kubectl get pods -n jenkins | grep <job-name> | awk '{print $1}' | head -1) \
 -n jenkins

80% 是这几个原因：

证书过期（K8s 证书默认 1 年）
镜像拉取失败（私有仓库没配 imagePullSecrets）
jnlp-slave Pod Template 里 command / args 写错

十、写在最后

Jenkins 的"全"是把双刃剑——插件生态丰富意味着学习曲线陡。从 2004 年走到 2024 年，Jenkins 仍是大量企业 CI/CD 的"事实标准"（不是"应该"，是"事实上"）。如果你正在做新项目选型，可以看看 GitHub Actions（云原生、YAML 优先）或 Drone（容器化、声明式），但对存量 Jenkins 集群，升级到 JDK21 LTS、关闭指纹验证、清理无用插件，就能让 80% 的项目跑得更稳。

下一步建议：

Jenkins on K8s 的完整部署：Jenkins Master 也跑在 K8s 里 + dynamic Agent
Jenkins Configuration as Code (JCasC)：用 jenkins.yaml 管理所有插件、凭据、节点
Pipeline as Code：把 Jenkinsfile 放进 Git 仓库，Job 通过 Multibranch Pipeline 自动发现

2024+ 视角补充

本文写于 2024-09，2025-2026 期间 Jenkins 关键演进：

Jenkins 2.516.x LTS（2025-04 起）：JDK 17 / 21 双轨 LTS，JDK 11 LTS 已于 2024-09-24 停止安全补丁——本文内容完全契合
Jenkins Evergreen 持续完善：CD-as-a-Service 模式，与 Kubernetes Operator 深度集成
Jenkins on K8s Operator（jenkinsci/kubernetes-operator）：Jenkins Master 本身也跑在 K8s 上，生产级高可用 + 自动备份
Pipeline as Code 主导：Jenkinsfile + Multibranch Pipeline 成为 2025+ 事实标准，老的 FreeStyle Job 模式逐步淘汰
AI 辅助插件（2025+）：Jenkins 接入 LLM 做"日志摘要 + 失败原因诊断"，但仅作为辅助——核心编排仍是声明式流水线

实战建议（2025-2026 视角）：Jenkins 仍是 Java 后端 CI/CD 事实标准；GitHub Actions / GitLab CI 在新项目是强力竞争者，但存量 Jenkins 集群升级到 JDK 21 LTS + 跑在 K8s 上仍是 2025+ 主路线。

参考资料

Jenkins 官方文档：https://www.jenkins.io/zh/doc/
Jenkins 官方镜像：https://hub.docker.com/r/jenkins/jenkins
Jenkins K8s Operator：https://github.com/jenkinsci/kubernetes-operator
Kubernetes 插件：https://plugins.jenkins.io/kubernetes
Active Choices 插件：https://plugins.jenkins.io/uno-choice
Generic Webhook Trigger：https://plugins.jenkins.io/generic-webhook-trigger
钉钉自定义机器人：https://open.dingtalk.com/document/orgapp/custom-robot-access
企业微信群机器人：https://developer.work.weixin.qq.com/document/path/91770

敏捷开发与协作：22 款主流 CI 工具选型指南

Mon, 19 Jun 2023 00:00:00 +0800

选 CI 工具是每个研发团队的"必经之坑"——选错了，每次构建都在消耗工程师的耐心。本文整理了 22 款主流 CI 工具的核心特点，帮你按团队规模、技术栈、部署方式快速圈定候选。

一、为什么选 CI 工具这么难

CI 工具选型不是"哪个最好用"，而是"哪个最适合"：

团队规模：3 人小团队 vs 300 人大厂，工具能力需求天差地别
技术栈：Java/Maven vs Node/Yarn vs Python/Poetry，支持的 runner 生态决定成本
部署方式：自托管 vs SaaS，合规要求决定能不能用云
集成需求：Jira / Slack / Kubernetes / GitHub，集成越深切换成本越高

When to use：当你的团队：

每天有 5+ 次合并
跨 3+ 个服务/模块需要协调测试
需要"提交 → 测试 → 部署"全链路自动化

→ 必须有 CI。否则问题会累积到发布日爆炸。

二、22 款 CI 工具横向对比

#	工具	类型	核心特点	适用场景
1	Buddy	SaaS	15 分钟配置，100+ ready-to-use actions，YAML 支持	Web 项目快速上手
2	Jenkins	自托管	海量节点、Java 编写、跨平台	大型企业、复杂流水线
3	TeamCity	自托管/SaaS	强大的 DSL、可在代码中配置构建	JetBrains 技术栈
4	Drone	自托管	原生 Docker、Kubernetes 友好	容器化项目
5	Travis CI	SaaS	曾经开源免费（注：2020 年后政策已变）、VM 构建、Slack/钉钉/企业微信通知	开源项目
6	GoCD	自托管	Value Stream Map 端到端可视化	复杂 CD 流水线
7	Bamboo	自托管	JIRA + Bitbucket 无缝集成	Atlassian 全家桶用户
8	GitLab CI	集成	与 GitLab 深度整合、API 丰富	GitLab 用户
9	CircleCI	SaaS/自托管	Docker 支持、并行测试、Android/iOS 商店评级优化	移动端 + 后端
10	Codeship	SaaS	Basic/Pro 两版、CI/CD 高度可定制	中小团队
11	Buildbot	自托管	分布式并行、跨平台 Job	Python 项目、大规模测试
12	Nevercode	SaaS	全自动云构建、无服务器维护	移动端
13	Integrity	自托管	仅 GitHub、HTTP/AMQP/邮件通知	小型 GitHub 项目
14	Strider	自托管	Node.js + MongoDB、插件丰富	JS 团队
15	AutoRABIT	SaaS	Salesforce 专用、120+ 元数据类型	Salesforce 项目
16	FinalBuilder	Windows	图形化逻辑结构、try/catch 错误处理	Windows 桌面应用
17	Wercker	SaaS	容器构建部署、100+ 外部工具集成	中小项目
18	Buildkite	自托管 agent	跨平台、密钥不读源码	安全敏感型项目
19	Semaphore	SaaS	配置简单、市场上最快的 CI 之一	追求速度的团队
20	CruiseControl	自托管	多 SCM 集成、远程管理	老牌 Java/.NET 项目
21	Bitrise	SaaS	移动 CI/CD 专用、虚拟机构建	移动端项目
22	UrbanCode	企业	混合云、审计、拖放自动化	大型企业、IBM 生态

三、按场景选型

3.1 小团队（≤10 人）、追求开箱即用

推荐：Buddy / GitHub Actions / GitLab CI

配置简单，15 分钟出第一条流水线
SaaS 免运维，省心
免费额度通常够用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# GitHub Actions 最小示例
name: CI
on: [push, pull_request]
jobs:
 test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - name: Run tests
 run: npm test

3.2 中型团队（10-50 人）、Java 技术栈

3.3 云原生团队

3.4 移动端团队

3.5 大型企业、合规优先

3.6 安全敏感型

四、CI 工具核心能力 6 维评估

选型时可以按这 6 维打分（1-5 分）：

维度	权重建议	评估点
易用性	中小团队高	配置门槛、文档质量、调试体验
可扩展性	大团队高	节点扩展、并发能力、插件生态
集成度	跨工具多	VCS、IM、制品库、K8s 集成
成本	看预算	免费额度、SaaS 月费、自托管人力
可观测性	重要	构建日志、Metrics、告警
安全性	合规项目高	密钥管理、审计日志、访问控制

五、核心 6 点提炼

CI 是工程效率的水电煤——选错一次，5 年都在为它还债。换 CI 比换语言还痛。
配置文件即代码——CI 脚本必须入库、评审、版本化。否则就是"工程师本机的玄学"。
缓存决定成本——依赖缓存（npm/node_modules、Maven .m2）能砍掉 50% 以上构建时间
并行测试是分水岭——单线程跑完 30 分钟，没人愿意等。拆 4 个 stage 并行 = 8 分钟
失败要快速反馈——编译/单元测试 5 分钟内出结果，否则工程师已经开始刷手机
制品（artifact）必须可追溯——CI 跑出的 jar/docker image，对应哪个 commit、哪个 PR，必须能查

六、常见 5 个坑

“用一个 YAML 写完所有 stage”——结果 stage 越来越多，构建越来越慢。正确做法：拆 pipeline
没做依赖缓存——每次 npm install 5 分钟，工程师一天等 1 小时。缓存命中 = 30 秒
密钥直接写在 YAML 里——密钥进入 git 历史 = 公开。用 Vault / CI 内置 secret 管理
CI 跑通 ≠ 测试覆盖——CI 绿色但单元测试覆盖 0%，线上还是炸。CI 必须有覆盖率门禁
不清理老构建——半年后构建历史 10 万条，磁盘爆掉。必须设 retention policy

七、CI 工具的"接力赛"

CI 工具不是孤立存在的，它在一个更大的"敏捷/协作"链条里：

1
2
3
4
5
6
7


需求 (Jira) → 代码 (Git) → CI (Jenkins/GitLab CI) 
 ↓ ↓
 评审 (Code Review) 制品 (Nexus/Artifactory) 
 ↓
 部署 (ArgoCD/Spinnaker) 
 ↓
 监控 (Prometheus/Grafana)

CI 工具的下一站是 CD。如果选了 CI 不支持 CD，可以叠加一个部署工具（ArgoCD / Spinnaker / Flux），但配置复杂度会上升。所以一开始就选支持 CD 的 CI 往往更省心。

八、迁移 CI 工具的代价

切换 CI 工具的真实成本（这是大多数团队低估的）：

任务	工作量
重新写所有 pipeline YAML	1-2 周
重写所有自定义脚本/插件	2-4 周
迁移构建历史/Metrics	1 周
培训团队	1-2 周
总代价	1.5-2 个月

建议：选 CI 工具时多花 2 周评估，比用上 2 年再换，省 6 个月。

九、2024+ 视角：5 款近 2 年主流 CI 的"上手 3 步"

2023 年后 CI 工具市场发生了一些显著变化：Travis CI 大幅收缩免费额度、Bitrise 移动端涨价、Drone 维护节奏放缓、GitHub Actions 几乎成了事实标准。下面是 5 款近 2 年仍在持续投入的工具，各给一个"3 步跑通"的最小实战。

9.1 GitHub Actions —— 开源/SaaS 首选

3 步上手：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 在仓库根目录创建 .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
 test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-node@v4
 with: { node-version: 20 }
 - run: npm ci && npm test

为什么选它：内置在 GitHub、零运维、海量 marketplace action、Windows/Mac/Linux runner 都免费。

9.2 GitLab CI —— 自托管/合规场景首选

3 步上手：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 仓库根 .gitlab-ci.yml
stages: [test, build]
test:
 stage: test
 image: node:20
 script: npm ci && npm test
build:
 stage: build
 image: docker:24
 services: [docker:24-dind]
 script: docker build -t myapp:$CI_COMMIT_SHA .

为什么选它：和 GitLab 仓库一体、Runner 私有部署方便、CI/CD 还能继续延伸到部署。

9.3 Drone —— 容器原生、轻量

3 步上手：

1
2
3
4
5
6
7
8


# 1. 仓库根 .drone.yml
kind: pipeline
type: docker
name: default
steps:
 - name: test
 image: node:20
 commands: [npm ci, npm test]

Server 端（docker compose）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


services:
 drone:
 image: drone/drone:2
 ports: ["8080:80"]
 environment:
 DRONE_GITHUB_CLIENT_ID: xxx
 DRONE_GITHUB_CLIENT_SECRET: xxx
 DRONE_RPC_SECRET: <random>
 DRONE_SERVER_HOST: drone.example.com
 drone-runner:
 image: drone/drone-runner-docker:1
 environment:
 DRONE_RPC_HOST: drone:9000
 DRONE_RPC_SECRET: <random>
 DRONE_RUNNER_CAPACITY: 2

为什么选它：单二进制部署、每步天然在容器中、配置文件和 GitHub Actions 一样简单。

9.4 Buildkite —— 安全敏感/金融/政企

3 步上手：

1
2
3
4
5


# 1. 仓库根 .buildkite/pipeline.yml
steps:
 - label: "Test"
 command: "npm ci && npm test"
 agents: { queue: "default" }

Agent 端（在企业内网跑）：

1
2
3
4
5
6


# 2. 内网机器装 agent
docker run -d \
 -e BUILDKITE_AGENT_TOKEN=<secret> \
 -e BUILDKITE_AGENT_NAME=$(hostname) \
 drone/drone-runner-docker:1
# 等价命令：buildkite-agent start --token <secret>

3. Web 后台（buildkite.com）开 Pipeline → 关联仓库 → agent 自动接活。

为什么选它：源代码/密钥不经过 Buildkite SaaS——CI 配置在云端、构建在内网，金融/军工场景的硬要求。

9.5 CircleCI —— Docker/Orb 生态

3 步上手：

1
2
3
4
5
6
7
8
9


# 1. 仓库根 .circleci/config.yml
version: 2.1
jobs:
 build:
 docker: [{ image: cimg/node:20.0 }]
 steps:
 - checkout
 - run: npm ci
 - run: npm test

为什么选它：Orb 复用机制强（类似 GitHub Actions 的 marketplace）、macOS M1 runner 是 iOS/macOS 开发的最优解。

9.6 2024+ 选型速查

场景	第一选择	备选
开源项目 / SaaS	GitHub Actions	CircleCI
自托管 + 合规	GitLab CI	Drone
容器化云原生	Drone	GitLab CI
金融/军工/源代码不出网	Buildkite	Jenkins（自建）
iOS/macOS CI	CircleCI	Bitrise
企业复杂流水线	Jenkins	TeamCity

十、结语

以下段落为引用 Rancher 官方介绍（写作时的产品现状描述，仅作历史背景参考）：

容器技术被越来越多地用于大型项目之中，如何通过一致的流程和工作流来简化大型项目的部署，变得愈发重要。Rancher Kubernetes 管理平台让用户通过一个自动化的过程，即可方便快速地创建及管理多 Kubernetes 集群。Rancher 平台对 Jenkins、GitLab CI、Drone 等流行的 CI 工具都提供了优秀的支持，内嵌的 Rancher Pipeline 也有着极简的操作体验和强大的功能整合。

作为用户，使用场景和需求都不尽相同，选择最适合自己的就好。

参考资料

GitLab CI 实战：GitLab EE 部署、Pipeline 接入 checkstyle 与 Java 项目自动化部署

Tue, 15 Jun 2021 00:00:00 +0800

GitLab 不只是一个"私有 GitHub"——从 2015 年起，GitLab 把 CI/CD 做成"开箱即用"的能力。GitLab CI 在很多公司里其实是比 Jenkins 更省心的选择：不用单独搭 CI 服务，仓库一推代码，.gitlab-ci.yml 一写，pipeline 自动跑。

但自托管 GitLab EE 镜像、Pipeline 跑 Java 构建、**代码规范检查（checkstyle）**这三件事串起来，有很多实战细节。这篇文章按"先把 GitLab 跑起来 → 接 Jenkins 做自动部署 → 集成 checkstyle"的顺序梳理——和之前 0.4 批次的"CI 工具对比"完全不同，本文只聚焦 GitLab CI + Java 这条具体路径。

阅读对象：需要从零搭一套自托管 GitLab，或正在用 GitLab 但想加 checkstyle / 自动化部署的开发者、运维
覆盖范围：GitLab EE 镜像部署、首次配置 / 创建用户 / SSH 免密、GitLab → Jenkins Webhook、Java 项目 Maven 构建、SSH 传包 + 远端 docker-compose restart、checkstyle 集成、.gitlab-ci.yml 完整模板

一、GitLab EE 镜像部署

1.1 选镜像

GitLab 的 Docker 镜像有三个变体：

镜像	用途
`gitlab/gitlab-ce:latest`	社区版（CE），免费，但功能受限（无 SAML、无审计、无 Geo 镜像等）
`gitlab/gitlab-ee:latest`	企业版（EE），有 30 天试用（License 文件未上传时仍可使用）
`gitlab/gitlab-ee:<version>`	指定版本的 EE 镜像

When to use：中小团队（< 50 人）用 CE 足够；对审计、合并审批、Geo 镜像、SCIM 等有要求选 EE。镜像体积大（约 2 GB），首次启动慢——容器内要执行 reconfigure 脚本。

1.2 docker-compose 部署

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# docker-compose.yml
version: '3'
services:
 gitlab:
 image: 'gitlab/gitlab-ee:13.12.9-ee.0'
 container_name: gitlab
 restart: always
 privileged: true
 ports:
 - '8000:80' # HTTP
 - '4433:443' # HTTPS
 - '2222:22' # SSH（宿主机 22 容易被占用，用 2222）
 volumes:
 - '/home/docker/gitlab/nginx.conf:/etc/gitlab'
 - '/home/docker/gitlab/logs:/var/log/gitlab'
 - '/home/docker/gitlab/data:/var/opt/gitlab'
 - '/etc/localtime:/etc/localtime:ro'

1

docker-compose up -d

坑 1：GitLab 启动慢是因为内部有 reconfigure（生成 nginx / sshd / postgresql 配置）、migrations（数据库迁移）。首次启动 5-10 分钟是正常的，用 docker logs -f gitlab | grep "Reconfigured" 跟踪进度。

1.3 首次访问

浏览器访问 http://<HOST>:8000/，首次进入会要求设置 root 密码。

坑 2：默认情况下 root 账号没有密码（启动日志里也没输出），必须通过 Web UI 第一次设置。设置后才能用 root 登录。

坑 3：HTTP 端口 80 → 宿主机 8000、SSH 端口 22 → 宿主机 2222 是常用的"避让"做法——宿主机 22 经常被 SSH 服务占用。

二、初始化项目仓库

2.1 关闭注册 + 创建用户

关闭公开注册：Admin Area → Settings → General → Sign-up restrictions → 关闭 Sign-up enabled

创建用户：Admin Area → Users → New User

2.2 创建第一个项目

用 admin 登录
项目 → New Project（或某用户的 Projects → New Project）
创建一个空项目 gutai/test
第一次提交时，项目 → Settings → Repository → Protected branches：受保护分支默认锁了 master，先解锁才能 push

2.3 SSH 免密推送（管理员操作）

生成 SSH 密钥（本地 Git Bash）：

1
2
3
4


ssh-keygen -t rsa -C '<YOUR_EMAIL>'
# 一直回车
# 生成位置: C:\Users\<USERNAME>\.ssh\id_rsa
# 公钥: id_rsa.pub

配置 Git 全局：

1
2


git config --global user.name "<YOUR_NAME>"
git config --global user.email "<YOUR_EMAIL>"

把 id_rsa.pub 加到 GitLab：User Settings → SSH Keys → 粘贴 id_rsa.pub 内容

推送本地代码：

1
2
3
4
5
6
7


git init
git add .
git commit -m "init"
git remote add origin ssh://git@<HOST>:2222/gutai/test.git
git push -u origin master
# 第一次 push 会被 Protected branches 拒绝, 先在网页上解锁 master
git push -f origin master

坑 4：用 SSH 推送时，git@<HOST>:2222 的端口要带——ssh://git@<HOST>:2222/gutai/test.git 形式。如果用 HTTP 推送（http://<HOST>:8000/...），首次需要输入账号密码。

三、Java 项目自动化部署

3.1 整体流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


开发者 push 代码
 ↓
GitLab 触发 Webhook
 ↓
Jenkins 收到 Webhook
 ↓
Jenkins 拉代码 → mvn clean package
 ↓
SSH 传 jar 到目标服务器
 ↓
目标服务器 docker-compose restart

3.2 Jenkins 侧：Maven 任务 + Publish Over SSH

Jenkins 插件：

git / gitlab
Maven Integration
Publish Over SSH

Jenkins 系统配置：系统管理 → 系统配置 → Publish Over SSH

1
2
3
4
5
6
7


新增一个 SSH Server
 name: production-server
 Hostname: <INTERNAL_HOST>
 username: root
 use password auth
 password: <REDACTED>
 Remote directory: /home

3.3 任务配置

新建任务 → 构建一个 Maven 项目

源码管理：

1
2
3


Repository URL: http://<GITLAB>:8000/gutai/test.git
Credentials: <刚加的 root/密码>
Branches: */master

构建触发器：

1
2
3
4


Build when a change is pushed to GitLab
 → 点 "高级" → Generate Secret token
 → 复制生成的 token
 → 粘贴到 GitLab 项目的 Webhook

Build：

1
2


Root POM: jeecg-boot/pom.xml
Goals and options: clean install -P prod -Dmaven.test.skip=true

构建后操作：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Send build artifacts over SSH
 → SSH Server: production-server
 → Transfers:
 Source files: jeecg-boot/jeecg-boot-module-system/target/jeecg-boot-module-system-2.4.2.jar
 Remove prefix: jeecg-boot/jeecg-boot-module-system/target
 Remote directory: /home/project/gutai/backend
 Exec command:
 rm -f /home/project/gutai/backend/jeecg-boot-module-system-2.4.2.jar
 mv /home/jeecg-boot/jeecg-boot-module-system/target/jeecg-boot-module-system-2.4.2.jar /home/project/gutai/backend
 rm -rf /home/jeecg-boot
 cd /home
 docker-compose restart backend

丢弃旧的构建：

1
2


保持构建最大个数: 10
保持构建天数: 7

坑 5：Source files 路径要和 Maven 实际产出的 jar 路径完全一致——Jenkins 不会"模糊匹配"，路径写错就直接报"找不到文件"。

3.4 GitLab 侧：配 Webhook

GitLab 项目 → Settings → Webhooks：

1
2
3
4


URL: http://<JENKINS>/project/<JOB_NAME>
Trigger: Push events
 (可选) SSL verification: Enable SSL verification
Secret token: <Jenkins 生成的 token>

点击 “Add Webhook” → “Test” → “Push events”。

如果 200 OK 说明配置成功；如果 403 / 404 检查 Jenkins Job 的"构建触发器"是否勾选正确。

坑 6：GitLab 11+ Webhook 默认不允许内网地址——内网 IP 直接 403 “Url is blocked: requests to the local network are not allowed”。解决：Admin Area → Settings → Network → Outbound requests → 勾选 “Allow requests to the local network from hooks and services”。

3.5 提交触发验证

1
2
3
4
5
6


# 本地代码修改
echo "// test" >> README.md
git add .
git commit -m "test webhook"
git push origin master
# 30 秒内, Jenkins 应该有新构建被触发

四、集成 checkstyle：代码规范检查

为什么需要 checkstyle？mvn package 只编译过、mvn test 只跑单元测试——它们不检查命名规范、import 顺序、注释规范、代码风格。checkstyle 才是"代码可读性"的守门员。

4.1 checkstyle 的两种集成方式

方式 A：Maven 本地跑（开发期）

pom.xml 加：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


<build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-checkstyle-plugin</artifactId>
 <version>3.3.0</version>
 <configuration>
 <configLocation>checkstyle.xml</configLocation>
 <includeTestSourceDirectory>true</includeTestSourceDirectory>
 <consoleOutput>true</consoleOutput>
 <failsOnError>true</failsOnError>
 <linkXRef>false</linkXRef>
 </configuration>
 <executions>
 <execution>
 <id>validate</id>
 <phase>validate</phase>
 <goals>
 <goal>check</goal>
 </goals>
 </execution>
 </executions>
 </plugin>
 </plugins>
</build>

坑 7：默认 failsOnError=true —— 任意一行代码违反规范，mvn validate 就失败。建议先设 false 看报告，确认规则合适后再打开。

方式 B：CI 流水线跑（提交期）

GitLab CI 的 .gitlab-ci.yml 加：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


stages:
 - check
 - build
 - deploy

checkstyle:
 stage: check
 image: maven:3.9-eclipse-temurin-17
 script:
 - mvn checkstyle:check -Dmaven.test.skip=true
 allow_failure: true # 失败不阻塞后续 stage
 artifacts:
 when: always
 reports:
 junit: target/checkstyle-result.xml

坑 8：allow_failure: true 让 checkstyle 失败不阻塞——但生产项目应该改为 false，强制规范。

4.2 自定义 checkstyle 规则

checkstyle.xml 放在项目根目录（或 config/checkstyle/ 下）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
 "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
 "https://checkstyle.org/dtds/configuration_1_3.dtd">
<module name="Checker">
 <property name="charset" value="UTF-8"/>
 <property name="severity" value="warning"/>
 <property name="fileExtensions" value="java, properties, xml"/>

 <module name="TreeWalker">
 <!-- 命名规范 -->
 <module name="PackageName"/>
 <module name="TypeName"/>
 <module name="MethodName"/>
 <module name="LocalVariableName"/>
 <module name="MemberName"/>
 <module name="ParameterName"/>
 <module name="ConstantName"/>

 <!-- import 规范 -->
 <module name="AvoidStarImport"/>
 <module name="UnusedImports"/>
 <module name="ImportOrder">
 <property name="groups" value="java,javax,org,com,*"/>
 <property name="sortStaticImportsAlphabetically" value="true"/>
 </module>

 <!-- 代码风格 -->
 <module name="LeftCurly"/>
 <module name="RightCurly"/>
 <module name="WhitespaceAround"/>
 <module name="ArrayTypeStyle"/>
 <module name="MagicNumber"/>
 <module name="NeedBraces"/>
 <module name="EmptyBlock"/>
 <module name="MethodLength">
 <property name="max" value="200"/>
 </module>
 <module name="ParameterNumber">
 <property name="max" value="8"/>
 </module>
 </module>
</module>

4.3 进阶：把 checkstyle 接到 GitLab Merge Request

真实场景：开发提交 MR（Merge Request），CI 跑 checkstyle，有违规就阻止合并。

.gitlab-ci.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


include:
 - template: Security/Secret-Detection.gitlab-ci.yml

stages:
 - validate
 - build
 - deploy

validate:
 stage: validate
 image: maven:3.9-eclipse-temurin-17
 script:
 - mvn checkstyle:check
 rules:
 - if: $CI_MERGE_REQUEST_ID
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

GitLab 设置 MR 必跑 pipeline： 项目 → Settings → Merge requests → Merge checks → 勾选 "Pipelines must succeed" → 保存

这样配置后，MR 不跑过 checkstyle 就不能合并。

五、`.gitlab-ci.yml` 完整模板（Java + Docker）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75


image: maven:3.9-eclipse-temurin-17

variables:
 MAVEN_OPTS: "-Xms1g -Xmx2g -Dmaven.repo.local=$CI_PROJECT_DIR/.m2"
 MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version"
 DOCKER_REGISTRY: "<private-registry>"
 DOCKER_IMAGE: "$DOCKER_REGISTRY/$CI_PROJECT_PATH:$CI_COMMIT_SHORT_SHA"

stages:
 - test
 - build
 - push
 - deploy

# 单元测试
test:
 stage: test
 script:
 - mvn $MAVEN_CLI_OPTS test
 artifacts:
 when: always
 reports:
 junit:
 - "**/target/surefire-reports/TEST-*.xml"
 coverage_report:
 coverage_format: cobertura
 path: target/site/cobertura/coverage.xml
 coverage: '/Line coverage:\s*(\d+.\d+)\%/'

# 打 jar
build:
 stage: build
 script:
 - mvn $MAVEN_CLI_OPTS clean package -DskipTests
 artifacts:
 paths:
 - target/*.jar
 expire_in: 1 day
 only:
 - main
 - develop
 - /^release\/.*$/

# 构建并推送 Docker 镜像
docker-build:
 stage: push
 image: docker:20.10
 services:
 - docker:20.10-dind
 before_script:
 - echo "$DOCKER_REGISTRY_PASSWORD" | docker login -u "$DOCKER_REGISTRY_USER" --password-stdin $DOCKER_REGISTRY
 script:
 - docker build -t $DOCKER_IMAGE .
 - docker push $DOCKER_IMAGE
 only:
 - main
 - /^release\/.*$/

# 部署到 staging
deploy-staging:
 stage: deploy
 image: alpine:3.18
 before_script:
 - apk add --no-cache openssh-client
 - eval $(ssh-agent -s)
 - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
 - mkdir -p ~/.ssh && chmod 700 ~/.ssh
 - ssh-keyscan -H $STAGING_HOST >> ~/.ssh/known_hosts
 script:
 - ssh $STAGING_USER@$STAGING_HOST "docker pull $DOCKER_IMAGE && docker-compose -f /home/project/docker-compose.yaml up -d --no-deps backend"
 environment:
 name: staging
 url: http://$STAGING_HOST
 only:
 - develop

坑 9：DOCKER_REGISTRY_PASSWORD 走的是 GitLab CI/CD Variables（项目 → Settings → CI/CD → Variables），不要写在 .gitlab-ci.yml 里。建议加 masked: true + protected: true。

六、GitLab CI vs Jenkins：何时选哪个

维度	GitLab CI	Jenkins
学习曲线	低（一个 `.yml` 文件）	中（需配插件、节点、凭据）
插件生态	中（GitLab 官方 + 社区）	极强（1800+ 插件）
多语言支持	强（每个 stage 独立 image）	强
大规模 Runner 管理	较弱	强（K8s plugin 动态 Agent）
流水线即代码	原生支持	支持（`Jenkinsfile`）
适用场景	代码托管 + CI 一体化	已有 Jenkins 集群、复杂编排

真实情况：很多公司的混合架构是 GitLab 托管代码 + Jenkins 跑 CD——本文讲的"GitLab 触发 Jenkins"就是这个模式。如果你的项目全在 GitLab 里、部署也不复杂，直接 GitLab CI 一步到位；如果部署涉及多套环境（dev/test/staging/prod）+ 复杂审批，建议 GitLab CI 跑构建 + Jenkins 跑发布。

七、常见排错

7.1 GitLab Webhook 403 “Url is blocked”

症状：GitLab → 项目 → Webhooks → Test → Hook execution failed: URL is blocked

解决：Admin Area → Settings → Network → Outbound requests → 勾选 "Allow requests to the local network from hooks and services"

7.2 Jenkins 收到 Webhook 但 403

症状：GitLab Webhook 测试 200 OK，但 Jenkins Job 没触发

解决：检查 Jenkins 的"构建触发器"里 GitLab webhook URL 和 Secret token 与 GitLab 是否完全一致。

7.3 `mvn package` OOM

症状：Jenkins Slave OOMKilled

解决：在 MAVEN_OPTS 加 -Xmx2g；或换 K8s 动态 Agent（资源独立）。

7.4 checkstyle 输出乱码

症状：checkstyle 报告里中文乱码

解决：在 pom.xml 加：

1
2
3
4
5
6
7


<plugin>
 <artifactId>maven-checkstyle-plugin</artifactId>
 <configuration>
 <inputEncoding>UTF-8</inputEncoding>
 <outputEncoding>UTF-8</outputEncoding>
 </configuration>
</plugin>

7.5 GitLab Runner 启动慢 / 卡

GitLab Runner 是 GitLab CI 的执行器。自托管 Runner 推荐装在 K8s 上，配合 kubernetes executor：

1
2
3
4
5


# 在 K8s 上跑 GitLab Runner（Helm）
helm repo add gitlab https://charts.gitlab.io
helm install gitlab-runner gitlab/gitlab-runner \
 --set runnerRegistrationToken=<REGISTRATION_TOKEN> \
 --set rbac.create=true

八、写在最后

GitLab CI 的核心价值是 “一个 YAML 走完整条流水线”——不需要在 UI 上点几百次"保存"，所有配置都在 .gitlab-ci.yml 里。代码规范、单元测试、构建、推送镜像、部署——一条流水线串起来。

下一步建议：

Auto DevOps：GitLab 自带的"零配置"流水线（开箱即用）
GitLab Container Registry：仓库一开，镜像就推到 GitLab 自带 Registry
GitLab Geo：多地域镜像仓库（EE 特性）
多 Runner 节点：用 K8s executor 弹性伸缩 Runner

参考资料

GitLab 官方文档：https://docs.gitlab.com/
GitLab Docker 镜像：https://hub.docker.com/u/gitlab
checkstyle 规则参考：https://checkstyle.org/checks.html
Maven checkstyle 插件：https://maven.apache.org/plugins/maven-checkstyle-plugin/
.gitlab-ci.yml 完整参考：https://docs.gitlab.com/ee/ci/yaml/

Ci on Liangweidong's blog

Jenkins 镜像实战：JDK21 升级、Agent 集群、钉钉/企微通知、Kubernetes 动态 Agent 与流水线部署 Java/Golang/Vue

一、Jenkins 镜像选择：JDK8 / JDK11 / JDK21 LTS

1.1 最小启动：JDK8 老镜像

1.2 JDK11 升级路径（已被 JDK21 取代）

1.3 JDK21 升级路径（当前推荐）

二、必备插件清单

三、钉钉 / 企业微信通知：3 行就能接

3.1 钉钉机器人

3.2 企业微信机器人

3.3 在 Pipeline 里推 commit 信息

四、Agent 集群：JNLP 节点 + K8s 动态 Agent

4.1 JNLP Agent（传统固定节点）

4.2 Kubernetes 动态 Agent（推荐）

4.3 自定义 Agent 镜像（装 rsync + sshpass）

五、流水线：声明式 vs 脚本式

5.1 声明式（推荐）

5.2 脚本式（灵活但难维护）

六、Active Choices：多级参数级联

七、流水线部署三类项目：Java / Golang / Vue

7.1 部署 Java 项目

7.2 部署 Golang 项目

7.3 部署 Vue 项目

八、定时构建 + 自动合并代码

九、常见排错

9.1 “Waiting for Jenkins to finish collecting data” 等待时间长

9.2 中文乱码

9.3 IllegalArgumentException: No enum constant io.jenkins.plugins.localization_zh_cn.UserCommunityProperty.ShowConditions

9.4 Publish Over SSH 连接超时

9.5 流水线里 Git 拉取失败

9.6 Kubernetes 插件连接集群失败

十、写在最后

2024+ 视角补充

参考资料

敏捷开发与协作：22 款主流 CI 工具选型指南

一、为什么选 CI 工具这么难

二、22 款 CI 工具横向对比

三、按场景选型

3.1 小团队（≤10 人）、追求开箱即用

3.2 中型团队（10-50 人）、Java 技术栈

3.3 云原生团队

3.4 移动端团队

3.5 大型企业、合规优先

3.6 安全敏感型

四、CI 工具核心能力 6 维评估

五、核心 6 点提炼

六、常见 5 个坑

七、CI 工具的"接力赛"

八、迁移 CI 工具的代价

九、2024+ 视角：5 款近 2 年主流 CI 的"上手 3 步"

9.1 GitHub Actions —— 开源/SaaS 首选

9.2 GitLab CI —— 自托管/合规场景首选

9.3 Drone —— 容器原生、轻量

9.4 Buildkite —— 安全敏感/金融/政企

9.5 CircleCI —— Docker/Orb 生态

9.6 2024+ 选型速查

十、结语

参考资料

GitLab CI 实战：GitLab EE 部署、Pipeline 接入 checkstyle 与 Java 项目自动化部署

一、GitLab EE 镜像部署

1.1 选镜像

1.2 docker-compose 部署

1.3 首次访问

二、初始化项目仓库

2.1 关闭注册 + 创建用户

2.2 创建第一个项目

2.3 SSH 免密推送（管理员操作）

三、Java 项目自动化部署

3.1 整体流程

3.2 Jenkins 侧：Maven 任务 + Publish Over SSH

3.3 任务配置

3.4 GitLab 侧：配 Webhook

3.5 提交触发验证

四、集成 checkstyle：代码规范检查

4.1 checkstyle 的两种集成方式

4.2 自定义 checkstyle 规则

4.3 进阶：把 checkstyle 接到 GitLab Merge Request

五、.gitlab-ci.yml 完整模板（Java + Docker）

六、GitLab CI vs Jenkins：何时选哪个

七、常见排错

五、`.gitlab-ci.yml` 完整模板（Java + Docker）

7.3 `mvn package` OOM