Go test -json 输出格式怎么用才不被 Jenkins/CI 工具丢掉失败详情
Go 原生 go test -json 是云原生 CI 中对接测试报告的唯一可靠出口，但直接塞进 Jenkins 或 Tekton 里常出现「显示通过但实际失败」「没堆栈」「跳过用例不识别」等问题——根本原因是多数 CI 工具只解析 action=="fail" 或 action=="output"，却忽略 action=="run" 和 action=="end" 的配对关系。
- 必须加
-v：没有-v，go test -json不输出单个测试的output字段，Jenkins 的 JUnit 插件就抓不到错误日志 - 避免管道截断：别写
go test -json -v | jq ...，JSON 流是逐行的，但部分jq版本会缓冲导致 EOF 前丢最后几行；推荐用go test -json -v 2>&1 | tee report.json先落地再处理 - 注意并发干扰：多个
go test并行跑时，-json输出会混在一起；CI 中应确保每个包单独执行，或用go test -json -v ./... > all.json（不推荐，包间顺序不可靠）
把 go test -json 转成 Jenkins 能认的 JUnit XML 有哪些坑
很多团队用 gotestsum 或自写脚本转 JSON → XML，但 Jenkins 的 JUnit Plugin 对 XML 结构极其敏感：字段名大小写、嵌套层级、时间单位、缺失字段都会导致解析失败或数据丢失。
-
time字段必须是秒级浮点数：Go 输出的是纳秒整数（如"time":123456789），XML 里得转成123.456789，否则 Jenkins 显示为 0s -
<failure></failure>必须包含message和type：仅写<failure>panic: xxx</failure>不生效；正确写法是<failure message="panic: xxx" type="panic">...stack...</failure> - 跳过测试（
action=="skip"）要映射为<skipped></skipped>，不能忽略，否则覆盖率统计偏差 - 别用
github.com/jstemmer/go-junit-report：它已归档，且不支持 Go 1.21+ 的新 JSON 字段（如test_binary），推荐用gotestfmt --format junitxml（v2.4+）或轻量脚本手动映射
在 Tekton Pipeline 中捕获和上传 Go 测试报告的最小可行路径
Tekton 没有内置测试报告解析器，得靠 Task 自己处理输出。关键不是“怎么生成 XML”，而是“怎么让 XML 在 Task 失败时不被丢弃”。
- 测试命令必须放在
script块末尾，且显式exit 0：Tekton 默认把非零退出当 Task 失败，整个工作区清空，XML 文件就没了 - 用
workspaces挂载共享卷存报告：别依赖$(workspaces.ws.path)下临时目录，CI 运行时可能被清理；固定路径如/workspace/report/report.xml - 上传动作（如
gsutil cp或curl -F）必须独立于测试命令：写成go test -json -v && convert-to-xml && upload会导致任一环节失败整个 Task 失败；拆成两个step，第二个 step 的onFailure: continue - 注意
go test的 exit code：即使有失败用例，go test -json仍返回 0；必须解析 JSON 流判断是否有action=="fail"才决定最终 exit code
Go 测试报告里哪些字段影响覆盖率和 flaky test 识别
单纯展示“通过/失败”没意义，CI 真正需要的是可追溯的执行上下文。Go 的 -json 输出里几个冷门字段，直接决定你能不能查清为什么某个测试在 CI 里随机失败。
立即学习“go语言免费学习笔记（深入）”；
-
Test字段值是完整包路径 + 函数名（如"TestServer/with_timeout"），不是短名；做 flaky 分析时必须用这个做唯一键，别截取with_timeout单独匹配 -
Elapsed是纳秒整数，可用于识别慢测试：CI 中设阈值（如 >3s）自动标为 performance warning，但注意 Docker 容器内 wall-clock 时间可能漂移 -
Output字段含 panic 堆栈时，开头常带=== RUN TestXxx\n--- FAIL: TestXxx (0.00s)\n xxx_test.go:123\n panic: ...—— 解析时要跳过前两行，否则 XML 里 failure message 会混入 RUN/FAIL 行 - 没有
File或Line字段：Go 不在 JSON 里暴露失败位置，只能从Output正则提取，比如(\w+\.go:\d+)，这是最易漏掉的调试线索
最麻烦的其实是测试二进制本身被缓存：Go build cache 在 CI 中复用时，go test -json 可能根本不运行测试函数，report 里连 action=="run" 都没有。每次 CI 都该加 -count=1 -race 或清 GOCACHE=off，不然看到的压根不是真实执行流。
