很多团队在引入代码评审流程后都会遇到一个现实问题代码提交到 Gerrit 之后评审人手动拉代码、编译、跑测试一轮下来少则十几分钟多则半小时。如果一天有几十个提交这种重复劳动几乎把评审人的耐心磨光。我所在的团队早期也是这样后来把 Jenkins 和 Gerrit 串起来提交一推到评审分支Jenkins 自动触发构建结果直接以评论形式回写到对应的 Patchset 上。评审人打开 Gerrit 就能看到这次提交是否编译通过、单测是否全绿效率提升非常明显。这篇内容就是围绕这套jenkins 部署流程和gerrit 对接展开把我在实际落地过程中踩过的坑、调过的参数、验证过的配置完整记录下来。不管你是刚接触 CI/CD 的新手还是已经用过 Jenkins 但没和 Gerrit 打通过的老手都可以跟着一步步复现。整套方案不依赖特定云厂商物理机、虚拟机、容器环境都能跑重点在于理解事件触发链路和权限模型。1. 整体方案设计与选型思考1.1 为什么是 Jenkins 加 Gerrit 这套组合Gerrit 本身是一个基于 Git 的代码评审系统它的核心能力是管理 Patchset、控制提交权限、记录评审意见。但它不负责构建也不负责跑测试。Jenkins 则是一个通用的自动化调度引擎擅长监听事件、执行任务、收集结果。把两者拼在一起就形成了“提交即验证”的闭环。具体链路是开发者向 Gerrit 推送一个 commitGerrit 生成一个 Patchset 并触发 refs/changes/xx/xx/x 这样的引用更新Jenkins 上的 Gerrit Trigger 插件监听到这个事件拉取对应 Patchset 的代码执行构建脚本构建结束后Jenkins 把结果通过 SSH 或 REST 接口回写到 Gerrit 的评论中同时给 Code-Review 或 Verified 标签投票。这套组合最大的好处是“不侵入开发习惯”。开发者仍然用 git review 或 git push 到 refs/for/ 分支不需要额外操作。评审人也不需要手动触发构建所有验证自动完成。相比 GitLab CI 或 GitHub ActionsGerrit 的评审模型更严格适合对代码质量要求高、需要多人签署的团队。Jenkins 的插件生态也足够成熟尤其是 Gerrit Trigger 和 Gerrit Code Review 插件几乎覆盖了所有常见事件类型。1.2 部署架构与环境规划在动手之前先把部署架构定下来。我推荐的最小化架构是一台 Gerrit 服务器一台 Jenkins 服务器两者通过 SSH 和 HTTP 通信。如果资源有限也可以部署在同一台机器上但要注意端口冲突和用户权限隔离。Gerrit 默认使用 29418 端口提供 SSH 服务8080 端口提供 Web 服务Jenkins 默认使用 8080 端口如果同机部署需要把其中一个改成 8081 或其他端口。操作系统层面Ubuntu 20.04 或 22.04 LTS 比较稳妥CentOS 7/8 也可以但要注意 Java 版本。Gerrit 3.x 需要 Java 11 或 17Jenkins 2.4xx 以上版本也推荐 Java 11 或 17。我实测用 OpenJDK 17 跑 Gerrit 3.8 和 Jenkins 2.426 没有问题。内存方面Gerrit 至少 2GBJenkins 至少 4GB如果要跑大型 Java 项目构建建议 8GB 起步。磁盘空间要看构建产物大小通常 50GB 以上比较从容。网络规划上Jenkins 需要能访问 Gerrit 的 SSH 端口和 HTTP 端口Gerrit 需要能访问 Jenkins 的 HTTP 端口。如果跨网段要确保防火墙放行。另外建议给 Jenkins 和 Gerrit 都配置固定 IP 或域名避免后续插件配置里频繁改地址。1.3 版本与插件选型建议版本选择上Gerrit 推荐 3.8 或 3.9 的稳定版Jenkins 推荐 2.426 或 2.440 的 LTS 版本。不要盲目追新尤其是 Gerrit 的大版本升级经常伴随数据库结构变化升级成本不低。Jenkins 的 Gerrit Trigger 插件目前主流版本是 2.39 以上支持 Gerrit 3.x 的事件格式。另外需要安装 Credentials Binding、Git、Pipeline、SSH Agent 等基础插件。需要特别留意的是Gerrit Trigger 插件在 Jenkins 2.4xx 之后有一些配置项位置调整网上很多老教程还是按旧版界面写的照着做会找不到入口。我建议直接看插件官方文档的截图或者按本文的路径操作。另外Gerrit 的 REST API 在 3.x 版本中默认需要认证回写评论时要么用 SSH要么用 HTTP 密码。SSH 方式更稳定后面会详细说。2. Jenkins 基础环境搭建与核心配置2.1 安装方式选择War 包、Docker 还是系统包Jenkins 的安装方式主要有三种直接下载 war 包用 java -jar 启动、通过 Docker 镜像运行、用 apt 或 yum 安装系统包。我个人最推荐 war 包方式原因是升级简单换一个 war 文件重启即可而且不会污染系统环境。Docker 方式适合已经容器化的团队但要注意数据卷映射否则重启后配置全丢。系统包方式安装的服务管理方便但升级时依赖包管理器有时会遇到版本滞后。如果用 war 包命令很简单mkdir -p /opt/jenkins cd /opt/jenkins wget https://mirrors.tuna.tsinghua.edu.cn/jenkins/war-stable/2.426.3/jenkins.war nohup java -jar jenkins.war --httpPort8080 jenkins.log 21 这里用了国内镜像加速下载速度会快很多。启动后访问 http://服务器IP:8080会看到解锁页面按提示从/root/.jenkins/secrets/initialAdminPassword或日志里获取初始密码。如果要用 Docker命令类似docker run -d --name jenkins \ -p 8080:8080 -p 50000:50000 \ -v /opt/jenkins_home:/var/jenkins_home \ jenkins/jenkins:2.426.3-lts不管哪种方式Jenkins 主目录JENKINS_HOME一定要持久化后面所有插件、任务、凭据都在里面。2.2 初始化配置与国内镜像加速解锁之后安装推荐插件那一步可以先跳过因为默认推荐里不一定包含 Gerrit Trigger。直接选择“选择插件来安装”然后什么都不选先创建一个管理员账号。进入主界面后第一件事是改插件更新源。默认的更新中心在国内访问很慢换成清华镜像进入Manage Jenkins - Plugins - Advanced settings把 Update Site 的 URL 改成https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json然后点击“Check now”再回到 Available 页面就能快速加载插件列表了。如果还是慢可以手动下载插件 hpi 文件用“Advanced - Upload Plugin”上传安装。我遇到过更新中心证书报错的情况这时候可以临时忽略证书检查但生产环境不建议长期关闭。接下来配置全局工具。进入Manage Jenkins - Tools配置 JDK、Git、Maven 等。JDK 可以填 JAVA_HOME 路径也可以让 Jenkins 自动安装。Git 建议填系统路径/usr/bin/git并指定版本。如果构建项目需要 Maven也在这里配置。注意如果 Jenkins 以 root 运行工具路径要确保 root 可访问。2.3 必备插件安装清单和 Gerrit 对接相关的插件主要有这几个插件名称作用是否必装Gerrit Trigger监听 Gerrit 事件、触发构建、回写结果必装Git plugin拉取 Gerrit 上的代码必装Pipeline支持 Jenkinsfile 流水线必装Credentials Binding在构建中安全使用凭据必装SSH Agent通过 SSH 密钥访问 Gerrit必装Build Name and Description Setter自定义构建显示名称可选DingTalk 或 Slack 通知构建结果推送可选安装 Gerrit Trigger 时Jenkins 可能会提示重启。重启后进入Manage Jenkins - Gerrit Trigger能看到全局配置页面。这里先不要急着填等 Gerrit 侧的账号和密钥准备好再回来配置。2.4 全局工具与凭据配置凭据管理是 Jenkins 里最容易出错的地方。和 Gerrit 通信至少需要两种凭据SSH 私钥和 HTTP 密码。SSH 私钥用于 Gerrit Trigger 连接 Gerrit 的 SSH 端口HTTP 密码用于回写评论或调用 REST API。我建议创建一个专门的 Jenkins 账号给 Gerrit 用不要用个人账号。添加 SSH 私钥的路径Manage Jenkins - Credentials - System - Global credentials - Add Credentials。类型选“SSH Username with private key”ID 可以填gerrit-jenkins-sshUsername 填 Gerrit 账号名例如jenkins-botPrivate Key 选“Enter directly”把生成的私钥内容粘贴进去。注意私钥格式要正确不能有多余的空格或换行错误。添加 HTTP 密码的路径类似类型选“Username with password”ID 填gerrit-jenkins-http用户名和密码就是 Gerrit 账号的 HTTP 凭据。如果 Gerrit 开启了 HTTP 密码认证可以在 Gerrit 的 Settings - HTTP Password 页面生成。这一步很多教程会漏掉导致后面回写评论时一直报 401。3. Gerrit 侧配置与 Jenkins 对接准备3.1 Gerrit 账号与权限模型Gerrit 的权限模型是基于项目的 Access 列表每个项目可以单独配置谁可以提交、谁可以评审、谁可以打标签。为了让 Jenkins 能拉取代码和回写结果需要给 Jenkins 账号分配以下权限Read允许拉取代码作用在refs/*。Label Verified允许给 Verified 标签投票作用在refs/heads/*或refs/changes/*。Stream Events允许通过 SSH 流式监听事件作用在refs/*。这个权限在 Gerrit 3.x 里叫“Stream Events”旧版可能叫“Event Stream”。Forge Committer或Forge Author如果 Jenkins 需要创建合并提交可能需要这个权限但一般 CI 不需要。配置路径进入 Gerrit 的Browse - Repositories - 选择项目 - Access点击“Edit”进入编辑模式。添加一个 Group把 Jenkins 账号加进去然后给这个 Group 分配权限。如果 Gerrit 开启了“继承项目权限”也可以在全局部配置。注意Gerrit 的权限修改后不会立即生效通常需要几秒钟到一分钟。如果 Jenkins 连接报权限错误先等一会儿再试。3.2 创建 Jenkins 专用账号与 SSH 密钥在 Gerrit 上创建一个新账号比如jenkins-bot邮箱可以填一个内部邮箱。然后用这个账号登录 Gerrit进入Settings - SSH Keys添加 Jenkins 服务器的公钥。公钥可以在 Jenkins 服务器上用ssh-keygen -t rsa -b 4096 -C jenkinsgerrit生成默认保存在~/.ssh/id_rsa.pub。把公钥内容粘贴到 Gerrit 的 SSH Keys 页面。同时在Settings - HTTP Password页面点击“Generate new password”把生成的密码记下来。这个密码就是后面 Jenkins 凭据里的 HTTP 密码。注意如果 Gerrit 配置了反向代理HTTP 密码的生成可能依赖认证方式确保 Gerrit 的auth.type设置为HTTP或HTTP_LDAP。测试 SSH 连接ssh -p 29418 jenkins-botgerrit.example.com gerrit version如果返回 Gerrit 版本号说明 SSH 通了。如果报 Permission denied检查公钥是否添加正确以及 Gerrit 的 SSH 端口是否开放。3.3 Gerrit 触发插件与事件流配置Gerrit Trigger 插件依赖 Gerrit 的 Event Stream。Gerrit 默认会通过 SSH 的gerrit stream-events命令推送事件但需要用户有Stream Events权限。可以在 Gerrit 服务器上手动测试ssh -p 29418 jenkins-botgerrit.example.com gerrit stream-events如果卡住不动说明连接成功正在等待事件。此时在另一个终端提交一个 Patchset应该能看到 JSON 格式的事件输出。如果报错fatal: Not permitted说明权限没配好回到 Access 页面检查。另外Gerrit 3.x 默认可能禁用了stream-events的某些事件类型可以在gerrit.config里检查[event] streamEvents true但通常不需要改默认就是开启的。3.4 项目权限与 refs 配置Jenkins 拉取代码时需要访问refs/changes/xx/xx/x这样的引用。Gerrit 对这类引用的读取权限默认是继承的只要项目有 Read 权限就能读。但要注意如果项目开启了“只允许特定用户读取”Jenkins 账号必须显式加入。另外如果 Jenkins 要构建refs/heads/*分支也需要 Read 权限。对于回写结果Jenkins 需要向refs/changes/xx/xx/x写入评论。这实际上是通过 Gerrit 的 REST API 或 SSH 命令完成的需要Label Verified权限和Stream Events权限。如果只想回写评论而不投票可以不加 Label 权限但那样评审人看不到 Verified 标签体验会差一些。4. Jenkins 对接 Gerrit 实操全流程4.1 安装 Gerrit Trigger 插件并配置连接进入Manage Jenkins - Gerrit Trigger点击“Add New Server”。名称可以填gerrit-main。在“Gerrit Host”里填 Gerrit 服务器的域名或 IP但不要带http://或ssh://前缀只填主机名或 IP。SSH 端口填29418。用户名填jenkins-bot。SSH Key 选择前面创建的gerrit-jenkins-ssh凭据。配置完成后点击“Test Connection”如果显示“Success”说明连接正常。如果失败查看 Jenkins 日志jenkins.log常见错误有私钥格式错误、Gerrit 主机名解析失败、端口被防火墙拦截、Gerrit 账号权限不足。接着配置“Gerrit REST API”部分这里填 HTTP URL例如https://gerrit.example.com然后选择 HTTP 凭据gerrit-jenkins-http。有些团队用自签名证书Jenkins 会因为 SSL 证书验证失败而报错。可以在 Jenkins 启动参数里加上-Dorg.jenkinsci.plugins.gerrit.trigger.skipCertificateValidationtrue但生产环境建议导入正确的 CA 证书。4.2 创建流水线任务与源码管理配置新建一个任务类型选“Pipeline”或“Freestyle project”。如果项目简单Freestyle 足够如果要写复杂的构建逻辑建议 Pipeline。这里以 Pipeline 为例。在任务配置的“Pipeline”部分选择“Pipeline script from SCM”SCM 选 Git仓库 URL 填 Gerrit 的 HTTP 地址例如https://gerrit.example.com/a/项目名。注意 URL 里加/a/表示需要认证。凭据选择gerrit-jenkins-http。分支可以填refs/changes/xx/xx/x吗不行因为每次 Patchset 的 refs 都不同。Gerrit Trigger 插件会在触发时动态注入GERRIT_REFSPEC环境变量所以分支可以填$GERRIT_REFSPEC但 Freestyle 里直接填$GERRIT_REFSPEC可能不生效需要用插件的“Gerrit event”构建触发器配合。更稳妥的做法是在 Pipeline 里用checkout步骤指定refspeccheckout([ $class: GitSCM, branches: [[name: ${GERRIT_REFSPEC}]], userRemoteConfigs: [[ url: https://gerrit.example.com/a/项目名, credentialsId: gerrit-jenkins-http, refspec: ${GERRIT_REFSPEC} ]] ])注意${GERRIT_REFSPEC}是 Jenkins 环境变量在 Pipeline 里要用双引号或直接引用。如果拉取失败检查 Gerrit 的 HTTP 地址是否需要/a/前缀以及凭据是否有 Read 权限。4.3 触发器配置Patchset Created、Comment Added 等在任务配置里找到“Build Triggers”勾选“Gerrit event”。然后选择“Gerrit Project”填 Gerrit 上的项目名称比如platform/framework。Branches 可以填refs/heads/*或留空。触发条件至少勾选Patchset Created每次新提交或amend产生新的 Patchset 时触发。Comment Added当有人在 Gerrit 评论里输入recheck时重新触发这个很实用。Draft Published草稿发布时触发。如果项目有多个分支可以在“Branches”里用正则匹配。另外“Dynamic Trigger”可以配置更复杂的条件比如只对特定文件变更触发但一般不需要。注意Gerrit Trigger 的“Patchset Created”事件在 Gerrit 3.x 中默认只包含refs/changes/*的更新。如果代码是通过git push直接推到refs/heads/*而不是refs/for/*则不会触发。所以团队要统一用 Gerrit 的评审流程。4.4 构建脚本编写与结果回传 Gerrit构建脚本的核心是两件事编译测试、回写结果。Jenkins 的 Gerrit Trigger 插件会自动把构建结果SUCCESS/FAILURE回写到 Gerrit但前提是配置了“Gerrit Reporting Values”。在任务的“Gerrit event”配置下方有“Gerrit Reporting Values”部分可以设置 Verified 标签的投票值。例如构建成功Verified 1构建失败Verified -1构建不稳定Verified 0如果不想自动投票可以把“Gerrit Verified”设为“No vote”。但通常建议开启这样评审人一眼就能看到验证状态。对于 Pipeline回写评论可以用gerritReview步骤但需要安装 Pipeline 的 Gerrit 插件。更简单的方式是直接用 SSH 命令ssh -p 29418 jenkins-botgerrit.example.com gerrit review \ --message Build Success: ${BUILD_URL} \ --verified 1 \ ${GERRIT_CHANGE_NUMBER},${GERRIT_PATCHSET_NUMBER}这里${GERRIT_CHANGE_NUMBER}和${GERRIT_PATCHSET_NUMBER}是 Gerrit Trigger 注入的环境变量。如果使用 Freestyle可以在“Post-build Actions”里添加“Gerrit Review”填上消息和投票值。我踩过的一个坑是回写评论时消息里包含单引号或特殊字符导致 SSH 命令解析失败。解决办法是用双引号包裹消息或者用--message-file指定一个文件。另外如果构建时间较长Gerrit 可能会因为超时断开 SSH 连接可以在 SSH 命令里加-o ServerAliveInterval30。4.5 验证完整链路提交代码到自动构建配置完成后做一次端到端验证。在本地仓库创建一个测试提交git add . git commit -m test: trigger jenkins git push origin HEAD:refs/for/master推送后打开 Gerrit 页面应该能看到新的 Change。几秒钟内Jenkins 任务会被触发构建历史里出现新的构建记录。如果一切正常构建完成后 Gerrit 的 Change 页面会出现一条评论显示构建结果和 Verified 标签。如果没触发按以下顺序排查Gerrit 的 Event Stream 是否正常、Jenkins 的 Gerrit Trigger 连接是否正常、任务是否启用了 Gerrit event 触发器、项目名称是否匹配、分支是否匹配。我遇到过项目名称填错的情况Gerrit 上的项目名是platform/framework但任务里填成了framework导致事件被忽略。5. 常见报错与排查技巧实录5.1 连接类错误排查连接类错误最常见的是“Connection refused”或“Auth fail”。先确认 Gerrit 的 SSH 端口是否监听netstat -tlnp | grep 29418如果没监听检查 Gerrit 服务是否启动。如果端口通但认证失败用ssh -v查看详细日志ssh -v -p 29418 jenkins-botgerrit.example.com gerrit version日志里会显示使用了哪个私钥、是否被服务器接受。常见原因私钥没有加载到 Jenkins 凭据、公钥没有添加到 Gerrit、Gerrit 账号被禁用、SSH 配置里PubkeyAcceptedAlgorithms不匹配。新版 OpenSSH 默认禁用ssh-rsa如果 Gerrit 只支持 RSA 密钥需要在~/.ssh/config里加Host gerrit.example.com PubkeyAcceptedAlgorithms ssh-rsa5.2 权限与认证类错误排查权限错误通常表现为fatal: Not permitted或HTTP 401。对于 SSH 连接检查 Gerrit 的Stream Events权限。对于 HTTP 回写检查 HTTP 密码是否正确以及 Gerrit 的auth.type是否允许 HTTP 密码。如果 Gerrit 前面有反向代理确认代理是否正确传递了认证头。还有一个隐蔽的坑Gerrit 的refs/changes/*读取权限默认是继承的但如果项目设置了“Read”权限只对特定 Group 开放Jenkins 账号必须在这个 Group 里。可以在 Gerrit 的 Access 页面用“Test”功能模拟 Jenkins 账号的权限。5.3 构建触发失败排查构建触发失败但连接正常通常是事件过滤条件太严。检查任务里的“Gerrit Project”名称是否完全匹配 Gerrit 上的项目路径。Gerrit 的项目名是区分大小写的而且可能包含斜杠。Branches 字段如果填了master但实际提交到refs/for/master事件里的分支信息可能是master也可能带refs/heads/前缀建议用refs/heads/*或留空。如果配置了“Dynamic Trigger”检查过滤条件是否把事件排除了。另外Gerrit Trigger 插件有一个“Silent Mode”如果开启所有触发都会被忽略只记录日志。检查全局配置里是否误开了。5.4 构建结果无法回传排查构建成功但 Gerrit 上没有评论先看 Jenkins 构建日志里是否有“Gerrit review”相关输出。如果报ssh: connect to host ... port 29418: Connection refused说明回写时的 SSH 连接失败可能是 Jenkins 构建节点无法访问 Gerrit。如果报Permission denied检查 Jenkins 账号是否有Label Verified权限。另一个常见问题是GERRIT_CHANGE_NUMBER环境变量为空。这通常是因为构建不是由 Gerrit 事件触发的比如手动点击“立即构建”此时没有这些变量。回写脚本要先判断变量是否存在if [ -z $GERRIT_CHANGE_NUMBER ]; then echo Not a Gerrit triggered build, skip review. exit 0 fi5.5 常见问题速查表现象可能原因解决方向Test Connection 失败私钥错误、端口不通、权限不足用 ssh -v 测试检查 Gerrit Access提交后不触发构建项目名不匹配、分支过滤、Silent Mode核对项目名清空分支过滤关闭 Silent构建成功但无评论HTTP 凭据错误、Label 权限缺失检查 HTTP 密码添加 Verified 权限拉取代码失败refspec 错误、URL 缺 /a/用 $GERRIT_REFSPEC补全认证路径评论消息乱码特殊字符未转义用双引号或改用 --message-file6. 进阶优化与实战经验6.1 构建加速与缓存策略随着项目变大每次 Patchset 都全量编译会非常慢。我通常会在 Jenkins 上做几件事第一配置 Maven 或 Gradle 的本地仓库缓存把~/.m2/repository或~/.gradle/caches挂载到持久化目录避免每次重新下载依赖。第二使用git clone --reference或浅克隆减少拉取时间。第三把编译任务拆成并行阶段比如单元测试和静态检查同时跑。对于 Pipeline可以用parallel步骤parallel( unitTest: { sh ./gradlew test }, staticCheck: { sh ./gradlew checkstyleMain } )但要注意并行任务共享工作空间时可能冲突最好给每个分支单独的工作目录。6.2 多分支与多项目并行管理一个 Jenkins 实例往往要对接多个 Gerrit 项目。如果每个项目都建一个任务管理起来很累。可以用“Gerrit Trigger”的“Gerrit Project”支持多个项目在任务里添加多个项目名称。或者用 Jenkins 的“Multi-branch Pipeline”配合 Gerrit Trigger但 Multi-branch 对 Gerrit 的 refs 支持不够直接需要额外脚本。我的做法是按项目类型分组比如 Java 项目共用一个 Pipeline 模板通过参数传入项目名和构建命令。这样新增项目时只需复制任务并改几个参数不用重写整个脚本。另外可以用 Jenkins 的“Folder”功能把不同团队的任务分开避免权限混乱。6.3 通知集成与构建结果可视化构建结果除了回写 Gerrit还可以推送到团队聊天工具。Jenkins 有钉钉、企业微信、Slack 等插件。我常用钉钉机器人配置一个 Webhook在构建后发送消息post { success { dingtalk( robot: jenkins-robot, type: MARKDOWN, title: 构建成功, text: [### 项目${env.JOB_NAME}, ### 构建号${env.BUILD_NUMBER}, ### 耗时${currentBuild.durationString}] ) } failure { dingtalk( robot: jenkins-robot, type: MARKDOWN, title: 构建失败, text: [### 项目${env.JOB_NAME}, ### 构建号${env.BUILD_NUMBER}, ### 查看日志${env.BUILD_URL}] ) } }注意钉钉机器人有频率限制不要每个 Patchset 都发可以只在失败时发或者按项目配置。6.4 安全加固与凭据管理最后说安全。Jenkins 的凭据一定要加密存储不要写在脚本里。Jenkins 默认用hudson.util.Secret加密但如果 Jenkins 主目录权限没控制好凭据可能被读取。建议给 Jenkins 主目录设置700权限并且只允许 Jenkins 用户访问。Gerrit 的 Jenkins 账号只授予必要权限不要给管理员权限。SSH 私钥最好设置密码短语然后在 Jenkins 凭据里填上密码短语。如果团队规模大建议把 Jenkins 和 Gerrit 都接入 LDAP 或 OAuth 认证避免本地账号散落。另外定期轮换 Gerrit 的 HTTP 密码和 SSH 密钥尤其是在人员变动后。这套流程我在三个不同规模的团队里落地过最小的团队只有五个人最大的三十多人。核心配置几乎没变主要是权限和触发条件按需调整。如果你刚开始搭建议先在测试环境跑通一个最简单的 Java 项目把整条链路走通再逐步加复杂度。遇到报错不要慌Jenkins 和 Gerrit 的日志都很详细按日志里的关键词搜索基本都能找到答案。我个人的习惯是每次改配置前先备份JENKINS_HOME和 Gerrit 的site目录这样即使改坏了也能快速回滚。