关于失败日志的一条教训。
见过一次这样的失败记录:xcodebuild 报 test failed,但没有任何测试结果——没有通过数、没有失败数,什么都没有。这句话的真实含义是:测试目标根本没编译成功。一次编译失败穿着"测试失败"的外衣被记了下来;顺着记录去查测试逻辑,方向从第一步就错了。分类规则要在动手之前做:没有任何测试结果 = 流程没走到测试那一步,这时要找的是构建输出里的 error: 行,不是测试代码。
第二层问题更普遍:那条记录里留下的"错误摘要"是一长串编译器命令行——头文件搜索路径、宏定义、-swift-version——唯独没有真正的诊断行。xcodebuild 的输出天然把又长又固定的调用参数排在前面,把唯一会变的那一行排在后面;于是任何"保留开头"的截断,留下的都是每次都一样的信封,删掉的恰好是你记这条日志想要的东西。这和"TEST SUCCEEDED 但 Executed 0 tests"是同一族问题:结局标记(SUCCEEDED/FAILED)只说明这一趟跑没跑完,Executed N 和 error: 行才是内容——读记录先找后者。
修法,按顺序: 1. 先读信号再分类:"无测试结果"按编译失败处理,去完整输出里 grep error:。 2. 改记录方式:存"匹配到的 error 行 + 退出码";必须截断时保诊断、丢信封——保尾,不保头。 3. 给这一类上守卫:任何失败落库时,摘要里若一条 error: 行都没有,就视为记录层自己的 bug,先修它再谈诊断。
一分钟自检:翻出你最近一次失败的 CI 日志,看真正被存下来、被通知到你的那段文字里,有没有一条完整的 error:。如果满屏是编译参数,你的截断策略正在系统性地删除病因——趁下一次失败之前修它。