artifacts:reports:junit 是 GitLab 解析测试报告的唯一可靠入口,需同时满足 XML 符合 JUnit 规范(testsuites/testsute 根节点)和 CI 配置中显式声明该字段并指定相对 glob 路径。
artifacts:reports:junit 是唯一可靠入口GitLab 原生只识别符合 JUnit XML 规范的测试报告,且仅通过 artifacts:reports:junit 字段解析并展示。直接把任意 XML 当作普通 artifact 上传(比如用 artifacts:paths)不会触发测试统计、失败标记或界面聚合,等于白传。
关键点:不是“上传 XML”,而是“让 GitLab 正确解析它”。必须满足两个硬性条件:
testsuites 或 testsuite,含 testcase 子元素,failure/error 可选)artifacts:reports:junit,值为匹配到该 XML 的 glob 路径(如 **/TEST-*.xml)不同框架默认输出格式差异大,不加配置极易生成 GitLab 无法识别的 XML(比如 pytest 默认是 pytest-xunit 插件输出,但需指定参数;JUnit 5 需要 junit-platform-reporting 或 Surefire 配置)。
典型配置示例:
--junitxml=report.xml,CI 中写 artifacts:reports:junit: report.xml
maven-surefire-plugin 版本 ≥ 2.22.0,并在 pom.xml 中启用 useFile(默认开启),报告路径默认为 target/surefire-reports/TEST-*.xml
jest-junit reporter,设置 JEST_JUNIT_OUTPUT_DIR 和 JEST_JUNIT_OUTPUT_NAME,再在 CI 中指向该文件artifacts:reports:junit 的路径匹配陷阱这个字段不接受绝对路径,只接受相对于 job 工作目录(CI_PROJECT_DIR)的相对 glob。常见错误包括:
/builds/group/project/report.xml → 报错 “junit report not found”artifacts 阶段已结束 → XML 根本不存在**/*.xml 匹配到非测试报告(如 config.xml、pom.xml)→ GitLab 解析失败,整个 job 显示 “junit parsing failed”建议始终用最小精确匹配,例如 target/surefire-reports/TEST-*.xml 或 test-results/TEST-*.xml,并在 job 末尾加验证:
ls -l target/surefire-reports/TEST-*.xml || echo "No JUnit XML found!"
即使配置正确,报告也可能“上传成功但不可见”,原因往往不在上传本身:
exit 0):GitLab 不解析失败 job 的 junit 报告(即使文件存在)
testsuites 多根节点,只认单 testsuite;12.7+ 才完整支持主流框架输出最省事的验证方式:在 job 日志里搜 Uploading artifacts... 行,确认路径被列出;再进 Pipeline > Job > Tests 标签页,看是否显示“0 tests”还是具体数字——后者说明解析成功。
真正卡住的地方,往往是 XML 结构不符合 JUnit schema,而不是路径或语法写错了。