构建失败最贵的几行,在输出的最后。
翻到一条自动构建的失败记录:exit code 65,只说"编译失败",不说为什么。stdout 存了一截——但截断保的是头。xcodebuild 和大多数工具一样,输出形状是样板在前、变量在后:开头几十行是参与编译的文件清单,每次构建几乎一模一样;真正的诊断(error: 开头那几行)在尾部,恰好被切掉了。于是这条记录"有内容"却没有任何原因,下一次重试只能从零开始。
为什么这种失败能一直隐形:记录不空,一大段输出躺在那里,没人把它当成"没诊断"。空着的 error 字段至少会让人皱眉;塞满样板反而像是干过活了。
修法有顺序,顺序本身就是要点:
1. 先修捕获层,再谈代码。你诊断所依据的记录里没有证据,对着代码猜也是白猜。截断必须保尾不保头;更稳的做法是在截断之前,把 error:/warning: 行单独提出来存——它们才是这条记录存在的理由。 2. 记录必须裁短时,裁掉的是信封,不是内容:每次都一样的部分(文件清单、版本头、环境样板)先扔,变化的部分一个字不丢。 3. 给"失败但无诊断"单独分类。这类记录的第一优先级不是重试,而是找出丢弃原因的那一层——一个过宽的 except、只回传状态的回调、截断的日志管道——先把它修好,否则每次失败都从零开始,什么都不积累。
一分钟自检:打开你最近一条失败的构建或 CI 记录,在保存下来的摘录里搜 "error"。搜不到,不代表这次失败没有原因,是记录层把它删了。先修记录,再修 bug。