首页 / 资讯中心 / 文章详情

使用 pmdtester 为 PMD 做回归测试:本地运行、CI 集成与差异报告解读

使用 pmdtester 为 PMD 做回归测试:本地运行、CI 集成与差异报告解读 ★ FEATURED ARTICLE
静态分析代码质量【免费下载链接】pmdAn extensible multilanguage static code analyzer.项目地址https://gitcode.com/gh_mirrors/pm/pmd点击查看免费下载导读PmdtesterPMD Regression Tester是 PMD 项目自带的回归测试工具当开发者修复了一个 issue、新增或修改了一条规则后它会用同一组真实开源项目作为测试集对比“基线版本”与“改动版本”的扫描结果找出新增的违规new violations与移除的违规removed violations从而在问题合入主分支之前就暴露可能引入的误报false positive与漏报false negative。本文从官方文档 pmdtester.md 出发结合本仓库中实际的 CI 配置与回归测试脚本讲解如何在本地运行 pmdtester、它如何基于基线baseline工作、在 GitHub Actions 中如何自动产出并回评差异报告以及贡献者提交 PR 前后应当如何使用这些能力。Pmdtester 是什么按官方开发者文档的定义Pmdtester 是一个回归测试工具核心目标是确保修复一个 issue 之后不会给 PMD 引入新的问题或非预期行为新编写的规则能够按预期工作而不是产生大量意料之外的违规报告。它通过“改动前”与“改动后”两次扫描的差异对比来实现上述目标。回归差异报告regression difference report会以评论的形式回贴到 Pull Request 上供审阅者快速判断改动是否安全文档中即以 PR #1265 的评论为例说明这一机制。从仓库历史记录看pmdtester 最早是 2018 年 Google Summer of CodeGSoC项目的成果PR #1254 将 danger 与 pmdtester 集成进 Travis CIPR #1250 实现了 baseline 的自动上传PR #1290 创建了关于 pmdtester 的官方文档参见 release_notes_old_pmd6.md。此后 pmdtester 作为 Ruby gem 持续迭代仓库 release notes 中记录了它从 1.5.5 → 1.6.0 → 1.6.1 → 1.6.2 → 1.7.0 的版本演进参见 release_notes_old_pmd7.md。需要说明的是官方文档撰写时的 CI 载体是 Travis CI当前仓库已全面迁移到 GitHub Actions回归测试由.github/workflows/build.yml中的regressiontesterjob 承担详见下文“CI 集成”章节但 pmdtester 本身的工作方式与命令接口没有改变。在本地安装并运行 pmdtester安装pmdtester 以 Ruby gem 形式分发安装命令为gem install pmdtester --pre其中--pre表示安装预发布prerelease版本便于在正式版发布前使用最新功能。安装前请确保本机具备 Ruby 与 RubyGems 环境在 CI 场景下仓库通过.ci/files/Gemfile声明依赖gem pmdtester并使用bundle install安装参见 Gemfile。运行本地回归测试并生成差异报告官方文档给出的核心命令如下pmdtester -r YOUR_LOCAL_PMD_GIT_REPO_ROOT_DIR -b main -p YOUR_DEVELOPMENT_BRANCH各参数含义参数含义-r本地 PMD Git 仓库根目录--local-git-repo的简写pmdtester 需要从这个仓库读取历史、切换分支执行对比-b基线分支base branch通常为main-p开发分支patch branch即包含你的改动的分支命令执行完毕后回归差异报告会输出到当前工作目录下的target/reports/diff目录YOUR_WORKING_DIR/target/reports/diff这与 CI 中的产物路径完全一致GitHub Actions 中该目录会被打包为名为pmd-regression-tester的 artifact 上传见下文。本地运行的前提条件本地必须有一份完整的 PMD Git 仓库克隆且包含足够的历史记录pmdtester 需要计算 merge-base确定改动涉及的文件集合CI 中.ci/files/pmdtester_start.sh会为此额外git fetch25~150 条提交需要能访问 baseline 下载地址本地运行会从https://pmd-code.org/pmd-regression-tester/拉取基线数据参见.ci/files/pmdtester.rb中的--baseline-download-url参数或者按 pmdtester 自身文档配置本地基线。工作原理基线对比驱动的差异报告pmdtester 的核心思想是基线baseline对比维护者在main分支或每次发布时对一组固定的测试项目执行一次完整的 PMD 扫描把结果打包成基线文件当某个 PR 或开发分支提交改动时pmdtester 用改动后的代码重新扫描同一组测试项目逐项目、逐文件、逐规则对比两次结果生成 diff表示新增的违规-表示被消除的违规审阅者通过 diff 中新增违规的数量与内容判断改动是否引入误报通过移除的违规确认修复是否真正生效。基线从哪里来本仓库中基线由 CI 定期重建并上传快照基线.github/workflows/publish-snapshot.yml中的create-regression-tester-baselinejob 在每次main分支快照构建后以main为 patch 分支执行 pmdtester 的single模式把target/reports/main/打包为main-baseline.zip上传到pmd-code.org的pmd-regression-tester目录参见 publish-snapshot.yml。这正是 PR 构建时默认下载的基线。发布基线.github/workflows/publish-release.yml的create-regression-tester-baselinejob 在每次正式发布后以pmd_releases_${PMD_VERSION}为名生成并上传pmd_releases_${PMD_VERSION}-baseline.zip同时镜像一份到 SourceForge参见 publish-release.yml。发布流程文档将“为回归测试器创建并上传新的基线”列为每次发布必须完成的最后一步之一参见 releasing.md 及其中 “regression-tester: New release baseline is uploaded” 的发布检查清单。差异报告的内容CI 场景下报告目录中至少包含两个机器可读文件由.ci/files/pmdtester.rb写入summary.txt对 PR 审阅者友好的汇总文本会被直接贴到 PR 评论中conclusion.txt结论状态可取success/failure/skipped等用于驱动 GitHub check 的最终结论。当本次改动没有任何受影响的规则时pmdtester_start.sh会提前短路写入summary.txt为 “No regression tested rules have been changed.”、conclusion.txt为skipped跳过整个测试过程参见 pmdtester_start.sh。CI 集成GitHub Actions 中的 regressiontester 工作流回归测试 job.github/workflows/build.yml中的regressiontesterjob 是 PR 与 push 构建中的一环其关键配置如下参见 build.yml配置项取值 / 说明触发条件pull_request或push事件依赖compilejob 先完成超时时间60 分钟运行环境ubuntu-latest安装 Java 11 与 21、Ruby 4缓存按.ci/files/project-list.xml与.ci/files/Gemfile.lock的哈希建立缓存regressiontester-*复用测试项目依赖与vendor/bundle输入产物复用compilejob 产出的dist-artifact解压到pmd-dist/target避免重复构建 PMD执行入口.ci/files/pmdtester_start.sh输出产物target/reports/diff打包为 artifactpmd-regression-tester这里用了一个独立的构建缓存因为它包含测试项目如 Spring Framework及其依赖与普通构建缓存刻意隔离。事件分支处理与 git 历史准备.ci/files/pmdtester_start.sh参见 pmdtester_start.sh承担了 CI 侧的关键准备工作根据GITHUB_EVENT_NAME区分事件类型pull_request基线分支取GITHUB_BASE_REF通常是main改动分支取pull/{PR_NUMBER}/headpush推送到main时基线与改动分支都是main并通过PMD_REGRESSION_TESTER_PUSH_BEFORE来自 build.yml 注入的github.event.before记录“推送前”的 commit作为第二参考点推送到其他分支时则以main为基线。仅支持main作为基线分支否则直接报错退出为确保能找到改动分支与基线的 merge-base脚本先git fetch --depth25若尚未找到合并基点则继续加深至最多 150 条提交然后把本地main分支指向 merge-base供 pmdtester 计算改动文件集最后导出PMD_CI_BRANCHmainPR 场景下还导出PMD_CI_PULL_REQUEST_NUMBER执行bundle exec ruby .ci/files/pmdtester.rb。pmdtester.rb真正的调用入口.ci/files/pmdtester.rb参见 pmdtester.rb以 Ruby 方式调用 pmdtester 的 APIPmdTester::Runner.new(args).run其构造的参数与本地命令一一对应参数值作用--local-git-repo./pmd本地 PMD 仓库路径--list-of-project./pmd/.ci/files/project-list.xml测试项目清单--base-branchmain由PMD_CI_BRANCH注入基线分支--patch-branchHEAD改动分支--patch-config./pmd/.ci/files/all-regression-rules.xml参与回归的规则集--modeonline在线模式联网下载基线--auto-gen-config-自动生成仅含受影响规则的配置文件--keep-reports-保留各次运行的中间报告--error-recovery-单个项目失败不中断整体运行--baseline-download-urlhttps://pmd-code.org/pmd-regression-tester/基线下载地址--threads机器 CPU 核数并行扫描测试项目若运行异常脚本会兜底写出failure结论与提示维护者的 summary避免 CI 静默丢失信息参见 pmdtester.rb。报告如何回到 PRpublish-pull-requests 工作流回归报告产成后还需要被“发布”回 PR 页面。.github/workflows/publish-pull-requests.yml参见 publish-pull-requests.yml在 “Build Pull Request” 成功后运行仅限官方仓库pmd/pmd且该 workflow 不检出 PR 代码、不参与构建只处理产物安全可控下载docs-artifact与pmd-regression-tester两个产物用 AWS CLI 将docs与regression目录同步到 S3 桶pmd-pull-requests路径为pr-{PR_NUMBER}/{PR_SHA}/docs与pr-{PR_NUMBER}/{PR_SHA}/regression通过 CloudFront 提供 HTTPS 访问数据保留 60 天后自动清理因为 URL 中含 PR 的 head SHA更新 PR 会重新上传避免缓存穿透通过 GitHub CLI 为该 PR 的 commit 添加 commit status 与 check run结论取自conclusion.txt用sticky-pull-request-comment动作把summary.txt内容作为评论创建/更新到 PR 上并附上完整报告的链接。由于这些页面是短生命周期产物站点根目录配置了robots.txtDisallow: /以阻止搜索引擎收录参见 github_actions_workflows.md。回归测试的配置资产测试项目清单project-list.xml.ci/files/project-list.xml参见 project-list.xml定义了回归测试使用的真实世界测试项目涵盖多种语言项目语言固定版本 / tagcheckstyleJavacheckstyle-9.1spring-frameworkJavav5.3.13openjdk-11src/java.baseJavajdk-1128java-regression-testsJavamaindeclarative-lookup-rollup-summariesApex固定 commitfflib-apex-commonApex固定 commitapex-linksamples子目录Apexv2.3.0OracleDBUtilsPL/SQL固定 commitalsa-firmwareCv1.2.1每个project节点可配置如下元素理解它们有助于本地自定义自己的测试项目集type/connection/tag项目来源git与固定的检出点保证基线可复现src-subpath只分析仓库的某个子目录exclude-pattern排除特定路径如生成代码、非编译资源避免噪音build-command克隆后如何构建项目并产出classpath.txt——以 spring-framework 为例脚本会打几个 patch 以适配 Java 11 编译并生成createSquishClasspath任务来导出 classpathauxclasspath-command为 PMD 的类型解析type resolution提供 classpathcpd-options该项目参与 CPD重复代码检测时的语言、最小 token 数与内存上限等选项。参与回归的规则集all-regression-rules.xml.ci/files/all-regression-rules.xml参见 all-regression-rules.xml按规则分类目录bestpractices / codestyle / design / documentation / errorprone / multithreading / performance / security引用了Apex、PL/SQL、Java的全部规则。回归测试只覆盖规则发生变化的语言与类别pmdtester 会基于改动涉及的规则生成实际运行的子配置--auto-gen-config因此即使规则全集很大单次回归也只需要针对受影响的规则执行。Gemfile 依赖.ci/files/Gemfile声明了 CI 运行 pmdtester 所需的 Ruby 依赖pmdtester本体以及兼容新版 Ruby 所需的logger、ostruct、base64三个默认 gem参见 Gemfile。Gemfile.lock固定版本与 project-list.xml 共同构成回归测试的缓存键。贡献者视角提交 PR 前后该怎么做按官方贡献指南PR 会自动构建构建成功后PMD Regression Tester 会针对上述几个测试项目运行扫描并生成报告参见 contributing.md报告列出新增的违规改动可能引入的误报与移除的违规修复确实消除的漏报/误报帮助维护者避免意外引入 false positives 或 false negatives报告会作为评论回贴到 PR并额外以 commit status / check run 的形式标记结果success/failure/skipped如果改动不涉及任何受回归规则集覆盖的规则测试会以skipped快速通过报告内容为 “No regression tested rules have been changed.”。对贡献者而言最实用的自查路径是在本地提前运行gem install pmdtester --pre pmdtester -r YOUR_LOCAL_PMD_GIT_REPO_ROOT_DIR -b main -p YOUR_DEVELOPMENT_BRANCH然后检查YOUR_WORKING_DIR/target/reports/diff下的差异报告确认新增违规数量为 0或均为预期行为后再提交 PR可显著减少维护者在评审中的来回沟通成本。相关文档与深入阅读以下仓库内文档与本主题强相关可继续深入github_actions_workflows.mdGitHub Actions 各工作流的全貌含regressiontesterjob 与 PR 结果发布的说明contributing.md贡献指南中关于回归测试自动运行的部分releasing.md发布流程中基线创建与上传的步骤及检查清单infrastructure.md包括 pmdtester gem 发布相关的基础设施说明pmdtester.md本文依据的官方开发者文档仓库内的实际配置与脚本build.yml、publish-pull-requests.yml、publish-snapshot.yml、publish-release.yml、pmdtester.rb、pmdtester_start.sh、project-list.xml、all-regression-rules.xml。小结Pmdtester 为 PMD 这类规则引擎项目提供了一条可复现、自动化的回归防线它以固定的测试项目集和基线报告为参照把“规则改动是否引入新违规”变成一份可机器读取、可回贴到 PR 的差异报告。本文既覆盖了官方文档给出的本地安装与运行命令gem install pmdtester --pre、pmdtester -r ... -b main -p ...、报告目录target/reports/diff也基于仓库源码剖析了基线生成、CI job、事件分支处理、产物发布回 PR 的完整链路。无论你是想为本地改动做一次快速回归还是打算为项目扩展新的测试项目集都可以从上述配置资产出发把 pmdtester 跑起来。赞分享静态分析代码质量【免费下载链接】pmdAn extensible multilanguage static code analyzer.项目地址https://gitcode.com/gh_mirrors/pm/pmd点击查看免费下载相关推荐tinygrad Process Replay 内核回归测试指南原理、本地运行与 CI 集成tinygrad Process Replay 内核回归测试指南原理、本地运行与 CI 集成 导读 Process Replay 是 tinygrad 内置的人工智能深度学习大模型Earthly 集成测试指南在本地与 CI 中可复现地运行集成测试Earthly 集成测试指南在本地与 CI 中可复现地运行集成测试 单元测试只验证单一模块自身的行为天然没有外部依赖而集成测试需要验证服务与外部系统文件CI/CDDevOps构建工具RisingWave Iceberg E2E 测试指南本地运行、测试用例编写与 CI 集成RisingWave Iceberg E2E 测试指南本地运行、测试用例编写与 CI 集成 本文围绕 RisingWave 仓库中 e2e_test/iceb数据库流处理后端数据工程创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站