尧图网站建设 
Jenkins 核心贡献者指南从环境搭建、源码构建到提交 Pull Request 的完整工作流【免费下载链接】jenkinsJenkins automation server项目地址: https://gitcode.com/GitHub_Trending/je/jenkins本篇指南以 Jenkins 仓库根目录的 CONTRIBUTING.md 为骨架面向想要向 Jenkins 核心代码库贡献代码的开发者。文章完整覆盖该文档中的开发环境要求、快速构建 WAR、启动开发实例、前端资源构建、代码检查、测试策略与 Pull Request 提交流程并结合仓库内的 pom.xml、Jenkinsfile、.github/PULL_REQUEST_TEMPLATE.md 与 docs/MAINTAINERS.adoc 等源码与配置文件进行交叉印证帮助读者从能编译一路走到能合入。开始之前理解 Jenkins 核心的贡献范围Jenkins 是一个庞大的自动化服务器项目本仓库对应的是Jenkins 核心core代码库主要包含core核心运行时、cli命令行客户端、war可执行 Web 应用、test功能测试套件、bom物料清单与websocket等模块。贡献代码之前建议先熟悉仓库的整体结构例如核心入口 core/src/main/java/hudson/Main.java 与 core/src/main/java/hudson/model/Hudson.java。CONTRIBUTING.md明确提醒Jenkins 项目能贡献的不只是代码还包含文档、测试、翻译等途径。但本文聚焦于代码贡献这一条主路径从环境准备到 PR 合并逐层展开。环境准备JDK、Maven 与 IDE按官方文档要求开发 Jenkins 核心需要以下工具链工具版本要求备注JDK21 或 25项目常用 Eclipse Temurin 或 OpenJDK其他发行版亦可Apache Maven3.9.6 及以上项目通常使用最新的 Maven 版本IDE支持导入 Maven 项目即可IntelliJ IDEA 有额外建议见下文从仓库侧的实证来看JDK 21/25 的双版本矩阵同样体现在 CI 中仓库根目录的 Jenkinsfile 第 16-19 行定义了platforms: [linux, windows]与jdks: [21, 25]两个测试轴CI 会在这些组合上并行执行构建与测试。因此本地使用任一受支持 JDK 即可但提交 PR 前需确保在 CI 覆盖的 JDK 版本上通过。环境准备完成后可以先从 issue 跟踪器中标记为good first issue的问题入手——这类问题被官方视为新手友好的切入点。快速构建 WAR 文件构建 Jenkins 核心的流程围绕 Maven 展开。官方给出的最快路径命令是mvn -am -pl war,bom -Pquick-build clean install这条命令的含义拆解如下-pl war,bom只构建war与bom两个模块-amalso make同时构建这两个模块依赖的其他模块-Pquick-build激活quick-build配置文件跳过测试与大部分静态检查clean install清理并安装到本地仓库。构建完成后WAR 文件位于war/target/jenkins.war。仓库根目录 pom.xml 中可以看到quick-buildprofile 的实现细节第 412-454 行它设置了maven.test.skiptrue因此测试类不会编译构建产物中也不包含测试类它设置了strip.license.comments.skiptrue、remoteresources.skiptrue关掉了只在产出发布制品时才需要的工作它把license-maven-plugin的默认 execution 绑定到phasenone因为该插件生成的META-INF/licenses.xml只被 About Jenkins 页面读取缺失时 core/src/main/java/hudson/AboutJenkins.java 的相关方法会返回 null视图层已能处理这种情况。[!NOTE] 由于quick-build跳过了测试编译构建产物里没有测试类。如果之后想针对该构建产物运行测试需要去掉该 profile 或显式传-Dmaven.test.skipfalse。clean 与前端工具链的保留策略clean阶段会故意保留node/、node_modules/与.yarn/目录这样 Node 工具链和已下载的依赖包可以在多次构建之间复用。如果需要连同这些目录一起清理传-Dclean.node即可。从 pom.xml 第 515-534 行的maven-clean-plugin配置可以看到设计意图删除node/目录本身要花几秒删除后每次构建都只能从零开始重新安装 Node 和依赖而.yarnrc.yml设置了enableGlobalCache: false.yarn是包缓存的唯一副本所以构建脚本刻意保留它们。由于yarn install每次构建都在initialize阶段执行过期依赖会在下一次构建中自愈。跳过前端构建如果你只修改后端代码并且war/src/main/webapp/jsbundles已经由之前某次构建填充那么传-Dskip.frontendtrue可以跳过 Node 安装、yarn install和yarn build三个步骤。对应的开关定义在 pom.xml 第 103-105 行并由frontend-maven-plugin的多个 execution 读取第 478、489、500 行。启动与远程调试 WAR构建完成后即可通过 Java CLI 方式启动 Jenkins。如果不借助 Maven 插件调试 WAR可以给 Java 进程附加 Remote Debug Flags例如-agentlib:jdwptransportdt_socket,servery,suspendy,address*:5005然后把 IDE Debugger 附加到该端口上。启动开发实例hpi:run官方推荐用hpi:run启动开发实例mvn -pl war hpi:run该命令会 fork 一个独立的 JVM以与生产环境相同的方式在 Winstone 容器下服务war/target/jenkins。默认情况下Jenkins 地址为http://localhost:8080/jenkins/JENKINS_HOME为war/work可以通过系统属性覆盖默认值-Dport、-Dhost、-DjenkinsHome。热加载行为开发实例对以下修改会在下一次页面加载时生效war/src/main/webapp下的资源core/src/main/resources下的 Jelly 视图及其配套的.properties文件。而对Messages.properties的修改需要重启开发实例才生效——虽然无需重新打包但资源 bundle 会在 JVM 生命周期内被缓存。Java 代码的改动仍然需要重新构建。远程调试开发实例由于 Jenkins 现在运行在独立 JVM 中直接在 Maven 上挂调试器无法附加到 Jenkins 进程。需要传-Dmaven.hpi.debugtrue让 fork 出的 JVM 挂起并等待调试器接入也可以给该属性传入自定义的 JVM 调试字符串。运行 Yarn 前端构建如果本机已安装 Node.js可以直接用 Corepack 启用 Yarncorepack enable无需修改 PATH。否则构建 WAR 之后把 Maven 下载好的 Node 和 Yarn 加入 PATHexport PATH$PWD/node:$PWD/node/node_modules/corepack/shims:$PATH之后即可运行yarn安装依赖。仓库根目录的 package.json 定义了前端脚本yarn.lock 锁定了依赖版本。前端资源热更新webpack 开发服务器开发war模块的前端资源时需要同时运行两个进程终端一启动后端开发服务器mvn -pl war hpi:run终端二启动 webpack 开发服务器yarn startyarn start会把产物写入war/src/main/webapp/jsbundles而开发服务器直接伺服该目录因此浏览器刷新即可看到重新构建的 bundle无需重启后端。仓库根目录的 webpack.config.js 与 eslint.config.cjs 分别承载了打包与代码检查配置。代码检查Checkstyle、ESLint、Prettier、Spotless 与 StylelintJenkins 核心使用五类工具做代码检查工具用途配置位置CheckstyleJava 风格检查src/checkstyle/checkstyle-configuration.xmlSpotlessJava 自动格式化由 Maven 构建集成ESLintJavaScript 检查eslint.config.cjsPrettier前端格式化.prettierrc.jsonStylelintSCSS 检查.stylelintrc.js这些工具都配置为随 Maven 构建运行但在quick-buildprofile 下会被跳过。自动修复后端问题mvn spotless:apply查看前端问题yarn lint修复前端问题yarn lint:fix在 CI 侧Jenkinsfile 第 152-188 行展示了这些检查的实际落地核心维护团队通过recordIssues收集 Java 警告、Javadoc、SpotBugs、Checkstyle、ESLint 与 Stylelint 报告并配置了质量门禁例如 SpotBugs 新问题阈值 1、Checkstyle 总问题阈值 1 会导致构建标为不稳定。测试策略light-test / smoke-test / all-testsJenkins 核心仓库自带单元测试与功能测试。功能测试位于test模块源码见 test/src/test/java例如 test/src/test/java/hudson/cli/CLITest.java运行耗时较长即使服务器级机器也是如此。由于大部分测试会由持续集成实例运行提交 PR 前并不强制要求跑完全部测试套件。官方定义了 3 个测试 profile实现在 test/pom.xml 第 454-487 行Profile行为实现细节light-test只跑单元测试不跑功能测试在test模块设置skipTeststruesmoke-test单元测试 一部分功能测试通过 surefire 的groupsSmokeTest只运行被SmokeTest标签标记的测试all-tests运行全部测试含失败重跑默认激活条件是未显式传入-Dtest设置surefire.skipAfterFailureCount100即失败 100 个后停止除仓库内测试外还有独立的 Acceptance Test HarnessATH仓库承载额外的集成测试与 UI 测试。如果提出复杂的 UI 变更应为其新增 ATH 测试——仓库根目录的 ath.sh 即用于在 CI 中驱动 ATH 测试参见 Jenkinsfile 第 215-248 行的ath分支。提交变更Fork、分支与 Pull RequestJenkins 项目的源码仓库托管在 GitHub所有变更通过 GitHub Pull Request 流程提交与评审。提交步骤将仓库 fork 到自己的 GitHub 账号下然后 clone 到本地在本地创建独立分支推荐按功能命名提交变更并推送到 fork避免直接往master推在 GitHub Web UI 中点击New Pull Request选择jenkinsci作为base fork、master作为base然后点击Create Pull Request所有变更都会合入master分支随 Weekly 版本发布之后可能由 LTS 团队将变更 backport 到当前 LTS 基线按 .github/PULL_REQUEST_TEMPLATE.md 模板填写 PR 描述点击Create Pull Request等待 CI 结果与评审反馈并处理反馈若 3 天无反馈可以在评论区 pingjenkinsci/core-pr-reviewers通常需要 2 个 reviewer 批准、无未解决的修改请求且等待一段时间供他人反馈后才会合并。PR 模板的关键栏目仓库内的 .github/PULL_REQUEST_TEMPLATE.md 是一个非常结构化的模板其中的关键栏目包括Fixes #issue-number关联 issue 编号供 changelog 生成器提取Testing done说明测试方式前端变更需附前后对比截图Screenshots仅 UI 变更需要Proposed changelog entries以祈使语气书写的人类可读 changelog 条目Proposed changelog category通过/label命令设置类别如bug、major-rfe、into-lts、localization、skip-changelog等Proposed upgrade guidelines存在破坏性变更时才填写否则留N/ASubmitter checklist包含自动化测试要求、新 API 的Restricted/since TODOJavadoc 要求、新弃用 API 的Deprecated(since ...)要求、CSP 兼容性新 JS 不得内联、不得调用eval、依赖更新的外部 changelog 链接、新 API 至少一个使用方的链接等。模板头部还强调不要删除任何栏目即使不适用也保留原样因为这些栏目被 changelog 生成器和其他工具用于提取信息不符合模板的 PR 可能未经评审即被关闭。合并后的流程PR 就绪后仓库维护者会负责集成、准备 changelog并确保其随某个 Weekly 版本发布。PR 作者无需再做额外操作。PR 管理标签体系Jenkins 使用一套定义明确的标签标记 PR 的状态与内容完整列表见 GitHub 仓库的 labels 页官方文档对这些标签的定义如下标签含义needs-docsPR 缺少文档开发者文档如 Javadoc或用户文档如 Jenkins handbook需补充对应文档才能批准合并若文档属于独立仓库则需在另一仓库创建草稿态 PR 与代码 PR 同步评审needs-fixPR 存在尚未解决的修改请求修复且测试通过前不会合并needs-justificationPR 的动机不清晰、不完整或不够有说服力强烈建议使用设计文档、高层跟踪 epic、最小可复现示例MRE等needs-more-review缺少足够数量的领域专家评审可能因为变更复杂且解释不足或对方案缺乏共识on-holdPR 依赖某个事件事件完成前不能合并打标签时应附注释说明挂起原因proposed-for-close对下一步无共识或长期无进展打标签约一周后通常会被关闭达成共识后可以重新打开ready-for-merge已满足验收标准若无负面反馈通常约 24 小时内合并stalledPR 起步良好但需要额外努力才能完成且该努力似乎已被放弃鼓励其他人接手work-in-progressPR 仍在积极开发中尚未准备好接受最终评审其中ready-for-merge、stalled、proposed-for-close三个标签受时间约束打上ready-for-merge的 PR若无负面反馈约 24 小时后合并PR 超过一个月无活动会被标记为stalled标记stalled后再无活动一个月会被标记为proposed-for-close约一周后关闭以维持 PR 队列秩序。允许维护者直接编辑打开 PR 时勾选Allow edits by maintainers选项表示你接受维护者可能向你的 PR 分支推送新提交。有些维护者愿意在评审时顺手修复拼写错误和合并冲突因此接受维护者编辑可以加速 PR 合入。评审与合并规范核心维护者的视角CONTRIBUTING.md引用了 docs/MAINTAINERS.adoc 作为评审流程的完整说明。该文档明确Jenkins 核心服务数百万用户其 PR 评审与合并流程比大多数插件更严格。几个与贡献者直接相关的要点评审目标不仅评审代码还从产品管理视角审视变更在全局是否合理并非每个变更都应进入核心很多功能更适合做成插件独立发布兼容性项目长期保持向后兼容功能兼容与二进制/API 兼容破坏性变更仅在必要时接受验收条件至少 2 个批准、无未解决的修改请求、对话已结束或明确无阻塞ready-for-merge倒计时由真正打算合并的核心维护者打标签约 24 小时无负面反馈后合并例外skip-changelog的小改动只需 1 个批准24 小时等待期仍适用不改变主要功能的 typo 修复、不涉及生产代码的 Jenkinsfile 改动、master 构建损坏等场景可跳过 24 小时等待期合并前的时间窗口LTS 发布前一周第 3、7、11、15 周等不建议合并高风险或超大变更以免 Weekly 用户不得不在安全修复与可用性之间二选一此时可用on-hold标签挂起squash 策略不强制贡献者清理提交历史维护者可在合并时 squash评审者可添加squash-merge-me标签表明需要。IntelliJ IDEA 使用建议官方文档针对 IntelliJ 用户给出三条建议保存时的空白符处理在 Settings → Editor → General → On Save → Remove trailing spaces 中选择Modified lines最小化 diff让评审更聚焦禁用*通配导入生产代码不推荐*导入。在 Settings → Editor → Codestyle → Java 中把Class count to use import with *和Names count to use import with *都设为较大值如 100argLine相关缺陷规避{jenkins.addOpens}加入argLine暴露了 IntelliJ 的一个 bug上游已有补丁提案。在补丁发布前需要到Settings→Build, Execution, Deployment→Build Tools→Maven→Running Tests取消勾选传给 JUnit 进程的argLine。否则在 IntelliJ 中运行测试会报could not open {jenkins.addOpens}错误。前端代码格式化安装 JetBrains 的 Prettier 插件并按其官方页面说明配置触发方式On code reformatting 是个不错的选择。版权与贡献协议Jenkins 核心采用 MIT license捆绑的少数类除外具体要点所有贡献默认视为 MIT 许可除非显式声明其他许可与 MIT 不兼容的代码贡献会被拒绝MIT 兼容许可的贡献若并非必要也可能被拒绝不要求PR 提交者签署贡献者协议contributor agreement前提是代码基于 MIT 许可、且由已签署协议的核心成员合入但如果计划提交多个 PR官方仍鼓励签署贡献者协议签署也是获得核心仓库合并/推送权限、加入 Jenkins 安全团队等团队的强制前提。持续集成Jenkins 构建 Jenkins 自己Jenkins 项目的持续集成服务器就是 Jenkins 自己位于 ci.jenkins.io构建流程基于 Jenkins Pipeline。核心构建流程的代码就存放在仓库根目录的 Jenkinsfile 中。如果你想调整该构建流程例如增加更多检查直接提交 PR 即可。从 Jenkinsfile 可以看到 CI 的典型工作流在linux/windows与 JDK 21/25 的组合矩阵上并行执行clean install配合 Launchable 做测试子集选择PR 场景下按比例抽取测试最后归档 surefire 报告、汇总 JaCoCo 覆盖率与各类静态分析报告另外还有一个 ATH 分支在 linux JDK 21 firefox 上运行 ath.sh 的浏览器级验收测试。相关链接速查Jenkins 贡献入口页参与方式总览Jenkins 聊天频道核心仓库的good first issue列表docs/MAINTAINERS.adoc核心维护者的评审、合并与发布流程完整文档.github/PULL_REQUEST_TEMPLATE.mdPR 描述模板JenkinsfileCI 构建流程定义结语贡献 Jenkins 核心的最小行动清单用 JDK 21/25 Maven 3.9.6 搭好环境从good first issue起步用mvn -am -pl war,bom -Pquick-build clean install快速验证构建用mvn -pl war hpi:run启动开发实例验证行为用-Dmaven.hpi.debugtrue远程调试提交前运行mvn spotless:apply与yarn lint必要时yarn lint:fix按模板创建 PR说明测试情况与 changelog 条目等待 CI 与评审尊重标签与时间约束ready-for-merge后约 24 小时合并长期无活动会被标记stalled乃至proposed-for-close。【免费下载链接】jenkinsJenkins automation server项目地址: https://gitcode.com/GitHub_Trending/je/jenkins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jenkins 核心贡献者指南：从环境搭建、源码构建到提交 Pull Request 的完整工作流
Jenkins 核心贡献者指南从环境搭建、源码构建到提交 Pull Request 的完整工作流【免费下载链接】jenkinsJenkins automation server项目地址: https://gitcode.com/GitHub_Trending/je/jenkins本篇指南以 Jenkins 仓库根目录的 CONTRIBUTING.md 为骨架面向想要向 Jenkins 核心代码库贡献代码的开发者。文章完整覆盖该文档中的开发环境要求、快速构建 WAR、启动开发实例、前端资源构建、代码检查、测试策略与 Pull Request 提交流程并结合仓库内的 pom.xml、Jenkinsfile、.github/PULL_REQUEST_TEMPLATE.md 与 docs/MAINTAINERS.adoc 等源码与配置文件进行交叉印证帮助读者从能编译一路走到能合入。开始之前理解 Jenkins 核心的贡献范围Jenkins 是一个庞大的自动化服务器项目本仓库对应的是Jenkins 核心core代码库主要包含core核心运行时、cli命令行客户端、war可执行 Web 应用、test功能测试套件、bom物料清单与websocket等模块。贡献代码之前建议先熟悉仓库的整体结构例如核心入口 core/src/main/java/hudson/Main.java 与 core/src/main/java/hudson/model/Hudson.java。CONTRIBUTING.md明确提醒Jenkins 项目能贡献的不只是代码还包含文档、测试、翻译等途径。但本文聚焦于代码贡献这一条主路径从环境准备到 PR 合并逐层展开。环境准备JDK、Maven 与 IDE按官方文档要求开发 Jenkins 核心需要以下工具链工具版本要求备注JDK21 或 25项目常用 Eclipse Temurin 或 OpenJDK其他发行版亦可Apache Maven3.9.6 及以上项目通常使用最新的 Maven 版本IDE支持导入 Maven 项目即可IntelliJ IDEA 有额外建议见下文从仓库侧的实证来看JDK 21/25 的双版本矩阵同样体现在 CI 中仓库根目录的 Jenkinsfile 第 16-19 行定义了platforms: [linux, windows]与jdks: [21, 25]两个测试轴CI 会在这些组合上并行执行构建与测试。因此本地使用任一受支持 JDK 即可但提交 PR 前需确保在 CI 覆盖的 JDK 版本上通过。环境准备完成后可以先从 issue 跟踪器中标记为good first issue的问题入手——这类问题被官方视为新手友好的切入点。快速构建 WAR 文件构建 Jenkins 核心的流程围绕 Maven 展开。官方给出的最快路径命令是mvn -am -pl war,bom -Pquick-build clean install这条命令的含义拆解如下-pl war,bom只构建war与bom两个模块-amalso make同时构建这两个模块依赖的其他模块-Pquick-build激活quick-build配置文件跳过测试与大部分静态检查clean install清理并安装到本地仓库。构建完成后WAR 文件位于war/target/jenkins.war。仓库根目录 pom.xml 中可以看到quick-buildprofile 的实现细节第 412-454 行它设置了maven.test.skiptrue因此测试类不会编译构建产物中也不包含测试类它设置了strip.license.comments.skiptrue、remoteresources.skiptrue关掉了只在产出发布制品时才需要的工作它把license-maven-plugin的默认 execution 绑定到phasenone因为该插件生成的META-INF/licenses.xml只被 About Jenkins 页面读取缺失时 core/src/main/java/hudson/AboutJenkins.java 的相关方法会返回 null视图层已能处理这种情况。[!NOTE] 由于quick-build跳过了测试编译构建产物里没有测试类。如果之后想针对该构建产物运行测试需要去掉该 profile 或显式传-Dmaven.test.skipfalse。clean 与前端工具链的保留策略clean阶段会故意保留node/、node_modules/与.yarn/目录这样 Node 工具链和已下载的依赖包可以在多次构建之间复用。如果需要连同这些目录一起清理传-Dclean.node即可。从 pom.xml 第 515-534 行的maven-clean-plugin配置可以看到设计意图删除node/目录本身要花几秒删除后每次构建都只能从零开始重新安装 Node 和依赖而.yarnrc.yml设置了enableGlobalCache: false.yarn是包缓存的唯一副本所以构建脚本刻意保留它们。由于yarn install每次构建都在initialize阶段执行过期依赖会在下一次构建中自愈。跳过前端构建如果你只修改后端代码并且war/src/main/webapp/jsbundles已经由之前某次构建填充那么传-Dskip.frontendtrue可以跳过 Node 安装、yarn install和yarn build三个步骤。对应的开关定义在 pom.xml 第 103-105 行并由frontend-maven-plugin的多个 execution 读取第 478、489、500 行。启动与远程调试 WAR构建完成后即可通过 Java CLI 方式启动 Jenkins。如果不借助 Maven 插件调试 WAR可以给 Java 进程附加 Remote Debug Flags例如-agentlib:jdwptransportdt_socket,servery,suspendy,address*:5005然后把 IDE Debugger 附加到该端口上。启动开发实例hpi:run官方推荐用hpi:run启动开发实例mvn -pl war hpi:run该命令会 fork 一个独立的 JVM以与生产环境相同的方式在 Winstone 容器下服务war/target/jenkins。默认情况下Jenkins 地址为http://localhost:8080/jenkins/JENKINS_HOME为war/work可以通过系统属性覆盖默认值-Dport、-Dhost、-DjenkinsHome。热加载行为开发实例对以下修改会在下一次页面加载时生效war/src/main/webapp下的资源core/src/main/resources下的 Jelly 视图及其配套的.properties文件。而对Messages.properties的修改需要重启开发实例才生效——虽然无需重新打包但资源 bundle 会在 JVM 生命周期内被缓存。Java 代码的改动仍然需要重新构建。远程调试开发实例由于 Jenkins 现在运行在独立 JVM 中直接在 Maven 上挂调试器无法附加到 Jenkins 进程。需要传-Dmaven.hpi.debugtrue让 fork 出的 JVM 挂起并等待调试器接入也可以给该属性传入自定义的 JVM 调试字符串。运行 Yarn 前端构建如果本机已安装 Node.js可以直接用 Corepack 启用 Yarncorepack enable无需修改 PATH。否则构建 WAR 之后把 Maven 下载好的 Node 和 Yarn 加入 PATHexport PATH$PWD/node:$PWD/node/node_modules/corepack/shims:$PATH之后即可运行yarn安装依赖。仓库根目录的 package.json 定义了前端脚本yarn.lock 锁定了依赖版本。前端资源热更新webpack 开发服务器开发war模块的前端资源时需要同时运行两个进程终端一启动后端开发服务器mvn -pl war hpi:run终端二启动 webpack 开发服务器yarn startyarn start会把产物写入war/src/main/webapp/jsbundles而开发服务器直接伺服该目录因此浏览器刷新即可看到重新构建的 bundle无需重启后端。仓库根目录的 webpack.config.js 与 eslint.config.cjs 分别承载了打包与代码检查配置。代码检查Checkstyle、ESLint、Prettier、Spotless 与 StylelintJenkins 核心使用五类工具做代码检查工具用途配置位置CheckstyleJava 风格检查src/checkstyle/checkstyle-configuration.xmlSpotlessJava 自动格式化由 Maven 构建集成ESLintJavaScript 检查eslint.config.cjsPrettier前端格式化.prettierrc.jsonStylelintSCSS 检查.stylelintrc.js这些工具都配置为随 Maven 构建运行但在quick-buildprofile 下会被跳过。自动修复后端问题mvn spotless:apply查看前端问题yarn lint修复前端问题yarn lint:fix在 CI 侧Jenkinsfile 第 152-188 行展示了这些检查的实际落地核心维护团队通过recordIssues收集 Java 警告、Javadoc、SpotBugs、Checkstyle、ESLint 与 Stylelint 报告并配置了质量门禁例如 SpotBugs 新问题阈值 1、Checkstyle 总问题阈值 1 会导致构建标为不稳定。测试策略light-test / smoke-test / all-testsJenkins 核心仓库自带单元测试与功能测试。功能测试位于test模块源码见 test/src/test/java例如 test/src/test/java/hudson/cli/CLITest.java运行耗时较长即使服务器级机器也是如此。由于大部分测试会由持续集成实例运行提交 PR 前并不强制要求跑完全部测试套件。官方定义了 3 个测试 profile实现在 test/pom.xml 第 454-487 行Profile行为实现细节light-test只跑单元测试不跑功能测试在test模块设置skipTeststruesmoke-test单元测试 一部分功能测试通过 surefire 的groupsSmokeTest只运行被SmokeTest标签标记的测试all-tests运行全部测试含失败重跑默认激活条件是未显式传入-Dtest设置surefire.skipAfterFailureCount100即失败 100 个后停止除仓库内测试外还有独立的 Acceptance Test HarnessATH仓库承载额外的集成测试与 UI 测试。如果提出复杂的 UI 变更应为其新增 ATH 测试——仓库根目录的 ath.sh 即用于在 CI 中驱动 ATH 测试参见 Jenkinsfile 第 215-248 行的ath分支。提交变更Fork、分支与 Pull RequestJenkins 项目的源码仓库托管在 GitHub所有变更通过 GitHub Pull Request 流程提交与评审。提交步骤将仓库 fork 到自己的 GitHub 账号下然后 clone 到本地在本地创建独立分支推荐按功能命名提交变更并推送到 fork避免直接往master推在 GitHub Web UI 中点击New Pull Request选择jenkinsci作为base fork、master作为base然后点击Create Pull Request所有变更都会合入master分支随 Weekly 版本发布之后可能由 LTS 团队将变更 backport 到当前 LTS 基线按 .github/PULL_REQUEST_TEMPLATE.md 模板填写 PR 描述点击Create Pull Request等待 CI 结果与评审反馈并处理反馈若 3 天无反馈可以在评论区 pingjenkinsci/core-pr-reviewers通常需要 2 个 reviewer 批准、无未解决的修改请求且等待一段时间供他人反馈后才会合并。PR 模板的关键栏目仓库内的 .github/PULL_REQUEST_TEMPLATE.md 是一个非常结构化的模板其中的关键栏目包括Fixes #issue-number关联 issue 编号供 changelog 生成器提取Testing done说明测试方式前端变更需附前后对比截图Screenshots仅 UI 变更需要Proposed changelog entries以祈使语气书写的人类可读 changelog 条目Proposed changelog category通过/label命令设置类别如bug、major-rfe、into-lts、localization、skip-changelog等Proposed upgrade guidelines存在破坏性变更时才填写否则留N/ASubmitter checklist包含自动化测试要求、新 API 的Restricted/since TODOJavadoc 要求、新弃用 API 的Deprecated(since ...)要求、CSP 兼容性新 JS 不得内联、不得调用eval、依赖更新的外部 changelog 链接、新 API 至少一个使用方的链接等。模板头部还强调不要删除任何栏目即使不适用也保留原样因为这些栏目被 changelog 生成器和其他工具用于提取信息不符合模板的 PR 可能未经评审即被关闭。合并后的流程PR 就绪后仓库维护者会负责集成、准备 changelog并确保其随某个 Weekly 版本发布。PR 作者无需再做额外操作。PR 管理标签体系Jenkins 使用一套定义明确的标签标记 PR 的状态与内容完整列表见 GitHub 仓库的 labels 页官方文档对这些标签的定义如下标签含义needs-docsPR 缺少文档开发者文档如 Javadoc或用户文档如 Jenkins handbook需补充对应文档才能批准合并若文档属于独立仓库则需在另一仓库创建草稿态 PR 与代码 PR 同步评审needs-fixPR 存在尚未解决的修改请求修复且测试通过前不会合并needs-justificationPR 的动机不清晰、不完整或不够有说服力强烈建议使用设计文档、高层跟踪 epic、最小可复现示例MRE等needs-more-review缺少足够数量的领域专家评审可能因为变更复杂且解释不足或对方案缺乏共识on-holdPR 依赖某个事件事件完成前不能合并打标签时应附注释说明挂起原因proposed-for-close对下一步无共识或长期无进展打标签约一周后通常会被关闭达成共识后可以重新打开ready-for-merge已满足验收标准若无负面反馈通常约 24 小时内合并stalledPR 起步良好但需要额外努力才能完成且该努力似乎已被放弃鼓励其他人接手work-in-progressPR 仍在积极开发中尚未准备好接受最终评审其中ready-for-merge、stalled、proposed-for-close三个标签受时间约束打上ready-for-merge的 PR若无负面反馈约 24 小时后合并PR 超过一个月无活动会被标记为stalled标记stalled后再无活动一个月会被标记为proposed-for-close约一周后关闭以维持 PR 队列秩序。允许维护者直接编辑打开 PR 时勾选Allow edits by maintainers选项表示你接受维护者可能向你的 PR 分支推送新提交。有些维护者愿意在评审时顺手修复拼写错误和合并冲突因此接受维护者编辑可以加速 PR 合入。评审与合并规范核心维护者的视角CONTRIBUTING.md引用了 docs/MAINTAINERS.adoc 作为评审流程的完整说明。该文档明确Jenkins 核心服务数百万用户其 PR 评审与合并流程比大多数插件更严格。几个与贡献者直接相关的要点评审目标不仅评审代码还从产品管理视角审视变更在全局是否合理并非每个变更都应进入核心很多功能更适合做成插件独立发布兼容性项目长期保持向后兼容功能兼容与二进制/API 兼容破坏性变更仅在必要时接受验收条件至少 2 个批准、无未解决的修改请求、对话已结束或明确无阻塞ready-for-merge倒计时由真正打算合并的核心维护者打标签约 24 小时无负面反馈后合并例外skip-changelog的小改动只需 1 个批准24 小时等待期仍适用不改变主要功能的 typo 修复、不涉及生产代码的 Jenkinsfile 改动、master 构建损坏等场景可跳过 24 小时等待期合并前的时间窗口LTS 发布前一周第 3、7、11、15 周等不建议合并高风险或超大变更以免 Weekly 用户不得不在安全修复与可用性之间二选一此时可用on-hold标签挂起squash 策略不强制贡献者清理提交历史维护者可在合并时 squash评审者可添加squash-merge-me标签表明需要。IntelliJ IDEA 使用建议官方文档针对 IntelliJ 用户给出三条建议保存时的空白符处理在 Settings → Editor → General → On Save → Remove trailing spaces 中选择Modified lines最小化 diff让评审更聚焦禁用*通配导入生产代码不推荐*导入。在 Settings → Editor → Codestyle → Java 中把Class count to use import with *和Names count to use import with *都设为较大值如 100argLine相关缺陷规避{jenkins.addOpens}加入argLine暴露了 IntelliJ 的一个 bug上游已有补丁提案。在补丁发布前需要到Settings→Build, Execution, Deployment→Build Tools→Maven→Running Tests取消勾选传给 JUnit 进程的argLine。否则在 IntelliJ 中运行测试会报could not open {jenkins.addOpens}错误。前端代码格式化安装 JetBrains 的 Prettier 插件并按其官方页面说明配置触发方式On code reformatting 是个不错的选择。版权与贡献协议Jenkins 核心采用 MIT license捆绑的少数类除外具体要点所有贡献默认视为 MIT 许可除非显式声明其他许可与 MIT 不兼容的代码贡献会被拒绝MIT 兼容许可的贡献若并非必要也可能被拒绝不要求PR 提交者签署贡献者协议contributor agreement前提是代码基于 MIT 许可、且由已签署协议的核心成员合入但如果计划提交多个 PR官方仍鼓励签署贡献者协议签署也是获得核心仓库合并/推送权限、加入 Jenkins 安全团队等团队的强制前提。持续集成Jenkins 构建 Jenkins 自己Jenkins 项目的持续集成服务器就是 Jenkins 自己位于 ci.jenkins.io构建流程基于 Jenkins Pipeline。核心构建流程的代码就存放在仓库根目录的 Jenkinsfile 中。如果你想调整该构建流程例如增加更多检查直接提交 PR 即可。从 Jenkinsfile 可以看到 CI 的典型工作流在linux/windows与 JDK 21/25 的组合矩阵上并行执行clean install配合 Launchable 做测试子集选择PR 场景下按比例抽取测试最后归档 surefire 报告、汇总 JaCoCo 覆盖率与各类静态分析报告另外还有一个 ATH 分支在 linux JDK 21 firefox 上运行 ath.sh 的浏览器级验收测试。相关链接速查Jenkins 贡献入口页参与方式总览Jenkins 聊天频道核心仓库的good first issue列表docs/MAINTAINERS.adoc核心维护者的评审、合并与发布流程完整文档.github/PULL_REQUEST_TEMPLATE.mdPR 描述模板JenkinsfileCI 构建流程定义结语贡献 Jenkins 核心的最小行动清单用 JDK 21/25 Maven 3.9.6 搭好环境从good first issue起步用mvn -am -pl war,bom -Pquick-build clean install快速验证构建用mvn -pl war hpi:run启动开发实例验证行为用-Dmaven.hpi.debugtrue远程调试提交前运行mvn spotless:apply与yarn lint必要时yarn lint:fix按模板创建 PR说明测试情况与 changelog 条目等待 CI 与评审尊重标签与时间约束ready-for-merge后约 24 小时合并长期无活动会被标记stalled乃至proposed-for-close。【免费下载链接】jenkinsJenkins automation server项目地址: https://gitcode.com/GitHub_Trending/je/jenkins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考