artifacts:reports:junit 是 GitLab 解析测试报告的唯一可靠入口，需同时满足 XML 符合 JUnit 规范（testsuites/testsute 根节点）和 CI 配置中显式声明该字段并指定相对 glob 路径。
GitLab CI/CD 中 artifacts:reports:junit 是唯一可靠入口
GitLab 原生只识别符合 JUnit XML 规范的测试报告，且仅通过 artifacts:reports:junit 字段解析并展示。直接把任意 XML 当作普通 artifact 上传（比如用 artifacts:paths）不会触发测试统计、失败标记或界面聚合，等于白传。
关键点：不是“上传 XML”，而是“让 GitLab 正确解析它”。必须满足两个硬性条件：
- XML 文件必须严格遵循 JUnit 4/5 的结构（例如根节点为
testsuites或testsuite，含testcase子元素，failure/error可选） - CI job 配置中必须显式声明
artifacts:reports:junit，值为匹配到该 XML 的 glob 路径（如**/TEST-*.xml）
常见测试框架生成兼容 XML 的实操方式
不同框架默认输出格式差异大，不加配置极易生成 GitLab 无法识别的 XML（比如 pytest 默认是 pytest-xunit 插件输出，但需指定参数；JUnit 5 需要 junit-platform-reporting 或 Surefire 配置）。
典型配置示例：
-
pytest（Python）：运行时加
--junitxml=report.xml，CI 中写artifacts:reports:junit: report.xml -
Maven + JUnit 5（Java）：确保
maven-surefire-plugin版本 ≥ 2.22.0，并在pom.xml中启用useFile（默认开启），报告路径默认为target/surefire-reports/TEST-*.xml -
Jest（JS）：配合
jest-junitreporter，设置JEST_JUNIT_OUTPUT_DIR和JEST_JUNIT_OUTPUT_NAME，再在 CI 中指向该文件
artifacts:reports:junit 的路径匹配陷阱
这个字段不接受绝对路径，只接受相对于 job 工作目录（CI_PROJECT_DIR）的相对 glob。常见错误包括：
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
- 写成
/builds/group/project/report.xml→ 报错 “junit report not found” - 路径没跑完就上传：比如测试命令后台执行或异步完成，但
artifacts阶段已结束 → XML 根本不存在 - glob 过于宽泛：如用
**/*.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!"
上传后看不到报告？先查这三处
即使配置正确，报告也可能“上传成功但不可见”，原因往往不在上传本身：
- job 必须成功（
exit 0）：GitLab 不解析失败 job 的 junit 报告（即使文件存在） - XML 文件编码必须是 UTF-8 且无 BOM：某些 Windows 工具生成带 BOM 的 UTF-8，会导致解析中断
- GitLab 实例版本低于 12.7：旧版不支持
testsuites多根节点，只认单testsuite；12.7+ 才完整支持主流框架输出
最省事的验证方式：在 job 日志里搜 Uploading artifacts... 行，确认路径被列出；再进 Pipeline > Job > Tests 标签页，看是否显示“0 tests”还是具体数字——后者说明解析成功。
真正卡住的地方，往往是 XML 结构不符合 JUnit schema，而不是路径或语法写错了。
