Hacktoberfest 2022：Jenkins maven-snapshot-plugin 的改进实践
前言
2022 国庆假期，全国疫情多点开花，因家乡疫情的缘故未出京。
恰逢一年一度的 Hacktoberfest，它鼓励人们在金秋 10 月为开源做出贡献。
过去 9 年，在世界各地，有成千上万的开发者参与了 Hacktoberfest，他们通过行动对他们使用或喜欢的项目做出了支持。
当然，对于参与者，如果完成了 4 个 PR，并且排名是前 40000，Hacktoberfest 官方会提供奖项作为鼓励。
参与者可以选择获得两个奖项中的一个：以他们的名字种植一颗树，或一件 Hacktobeffest 2022 T 恤。
于是想着趁着国庆假期，完成一个小目标：给开源项目提交至少 4 个 PR，以便能够获得心仪的奖品： 一件 Hacktoberfest 2022 T 恤。
有一个不得不提的背景是，对于 2020 年参加 hacktoberfest 获得的 T-shirt，个人是非常喜欢的。
因为它的图案很漂亮，并且质量也不错，而且是独一无二的，具有一定的纪念意义。
有点遗憾的是 2021 年没有参与 hacktoberfest，所以决定今年必须参加 hacktoberfest 2022。
要参加 hacktoberfest，就需要给开源项目提交 PR/MR。
那么往哪个开源项目贡献 PR 呢？
个人非常认同 hacktoberfest 提出的价值观：
QUANTITY IS FUN, QUALITY IS KEY（数量是乐趣，质量是关键）
SHORT-TERM ACTION, LONG-TERM IMPACT（短期行动，长期影响）
相比于纯粹完成 PR 指标，更有价值的是做些对开源高质量，有意义的贡献，短期的参与可能对未来的人或技术有长久深远的影响。
作为 jenkins contributor，同时也是 jenkins maven-snapshot-plugin 的 maintainer。
想起不久前更新了下 jenkins maven-snapshot-plugin，因为测试不充分（均是手工测试）导致发布后出现了 bug。
于是便决定对 jenkins maven-snapshot-plugin 进行改进。
主要从三方面着手：修复 CI、开启 CD、增加及完善单元测试。
相关链接：
hacktoberfest: https://hacktoberfest.com/
Jenkins Maven SNAPSHOT Plugin: https://github.com/jenkinsci/maven-snapshot-check-plugin
修复 CI：让构建不再失败
此前， jenkins maven-snapshot-plugin 的 CI 构建失败已久，但因为插件没有新功能更新，所以一直没有去处理。
曾经成功的构建为什么会构建失败呢？是什么原因导致的呢？
查看构建日志，在构建日志中有如下报错：
从上面可以看出是 findbugs-maven-plugin 报错。
这里补充一下构建上下文信息：Apache Maven 3.8.6，Java version: 1.8.0_345。
查阅资料得知，这是因为 maven 的版本和 findbugs-maven-plugin 的版本不兼容。
要么降级 maven 的版本，要么升级 findbugs-maven-plugin 的版本。
从 findbugs-maven-plugin 的 github 仓库得知，findbugs 已于 2018 年不再维护，官方推荐使用 spotbugs。
spotBugs 是 findBugs 的精神继承者，在社区的支持下，从停止的地方继续前进。
所以，最好的解决方案是用 spotbugs，而不是再用 fingbugs，甚至去降级 maven 的版本。
因为 jenkins plugin 有统一的 parent pom，而 findbugs 配置正是来自 parent pom。
于是接着查看 parent pom 的 changelog，发现它在 3.36 版本用 spotbugs 替换了 findbugs。
在将 parent pom 的版本升级到 3.36 后，CI 的构建报错也迎刃而解。
相关链接：
Cannot assign configuration entry 'pluginArtifacts' with value '${plugin.artifacts}'： https://my.oschina.net/sprouting/blog/5192058
Upgrade findbugs-maven-plugin to 3.0.5 to fix mvn findbugs:findbugs failure： https://issues.apache.org/jira/browse/HADOOP-16869
findbugs-maven-plugin： https://github.com/gleclaire/findbugs-maven-plugin
Changelog for jenkinsci plugin-pom： https://github.com/jenkinsci/plugin-pom/blob/master/CHANGELOG.md#336
开启 CD：由手动发布转为自动化发布
此前，插件的发布是手动执行的。
手动发布的话，需要在本地进行，步骤大概如下：
配置 jdk、 maven 及 settings.xml
需要按照 jdk 并配置环境变量（推荐 jdk 8 或 jdk 11）
需要安装 maven 并配置环境变量
需要在 settings.xml 配置 jenkins repo 的 mirror 和 profile，以便能够下载 maven 插件和依赖
需要在 settings.xml 配置 jenkins repo server 的认证信息，以便能够 deploy 制品到 jenkins artifactory
配置 github ssh-key
当执行 release 时，maven-release-plugin 会自动往仓库推送代码， 所以需要在 github 上配置 ssh-key。
执行发布
推荐使用 maven-release-plugin 的命令：mvn release:prepare release:perform
在 github 上发布 release 以及 changelog
那么，转成自动化发布该如何做呢？
幸运的是，jenkins 官方提供了统一的解决方案，用于将手动发布的这些操作自动化。
只要按照 jenkins 官方的指南上的 checklist 一步步检查及修改，最后引入统一的 github actions 的 yaml 文件即可。
关于这个解决方案，需要注意以下几点：
没有采用语义化版本号（如：1.2.3），而是用了类似 123.vabcdef456789 作为版本号（其中 123 为 git 历史深度，vabcdef456789 为 git commit hash）
目前只支持 jdk 11（jenkins plugin 从 jdk 8 升级到 jdk 11，可能需要做一些代码修改）
只要 jenkins ci 构建成功，并且有一个 PR 有 enhancement label，那么就会自动发布
当然也可以手动执行发布
但是对于同一个版本，在发布之后，不允许覆盖
不需要使用个人的 artifactory 账号进行认证，而是使用 jenkins 官方统一提供和维护的 artifactory bot 的账号和 token
MAVEN_TOKEN、MAVEN_USERNAME 被配置在仓库的 secrets 中
出于安全考虑，这个 bot 的 token 会被定期自动更新
来自 Dependabot 的更新不会触发自动发布
相关链接：
Setting up automated plugin release： https://www.jenkins.io/doc/developer/publishing/releasing-cd/
JEP-229: Continuous Delivery of Jenkins Components and Plugins： https://github.com/jenkinsci/jep/blob/master/jep/229/README.adoc
jenkins-maven-cd-action： https://github.com/jenkins-infra/jenkins-maven-cd-action
增加及完善单元测试：通过自动化测试保证质量
最开始提到过，因为测试不充分（均是手工测试）导致发布后出现了 bug。
那么如果 CI 中有自动化测试，那么每次做了代码修改后，都会运行自动化测试。
如果 CI 失败，那么说明代码修改的可能有问题。这样就能尽早发现问题，以便尽早解决问题。
为了简化测试的开发，Jenkins 提供了一个基于 JUnit 测试框架的测试工具。它提供了以下功能：
自动设置和拆卸 Jenkins 安装，允许每个测试方法在干净、隔离的环境中运行。
帮助程序类和方法，以简化 job、agent、安全域、SCM 实现等的创建。
声明性注释，用于指定测试方法将使用的环境；例如，设置 JENKINS_HOME 内容。
直接访问 Jenkins 对象模型。这允许测试直接针对 Jenkins 的 内部状态进行断言。
HtmlUnit 支持，使测试与 web UI 和其他 HTTP 调用的交互变得简单。
有了强大的测试工具支持，开发者只需要关注自己要测试用例，比如：对插件提供的 step 的测试。
这里要提到的一点是如果是对 Pipeline 进行测试，目前只支持脚本式 Pipeline。
在引入一些测试依赖的时候，推荐使用 jenkins 官方提供的 BOM，这样无需指定每个依赖的版本号，也无需考虑不同依赖之间的兼容性问题。
另外，建议为仓库开启 Codecov 覆盖率监控，它支持覆盖率可视化，它可以监控每个 PR 覆盖率的变化。
它也可以看到那些行被覆盖、哪些行没有被覆盖、哪些行是部分覆盖。
当然，它的功能不限于此，此处不一一枚举。
如果你想提升代码覆盖率，它绝对是一个非常得力的助手。
相关链接：
Jenkins Testing： https://www.jenkins.io/doc/developer/testing/
Unit test framework for Jenkins core and its plugins： https://github.com/jenkinsci/jenkins-test-harness/
Jenkins BOM： https://github.com/jenkinsci/bom/blob/master/README.md
Codecov： https://about.codecov.io/
总结
以 hacktoberfest 2022 为契机，在国庆假期对 jenkins maven-snapshot-plugin 的 CI/CD 进行了一系列改进。
原本计划的 4 个 PR 超额完成，此外，在这个过程中还给 jenkins 官方文档提了两三个 PR。
个人觉得这个是非常有意义、有价值的事情，是以为记。
版权声明: 本文为 InfoQ 作者【donghui】的原创文章。
原文链接:【http://xie.infoq.cn/article/828745abeeb280324958955fd】。文章转载请联系作者。
公众号：ServerlessLife 2018.01.01 加入
还未添加个人简介
评论