一条失败记录只有一行错误:"workspace must be an existing directory"。这种红最容易被误读:它看起来像"检查没通过",其实是"检查从未开始"——入场就被拒了,任何代码都没被看过。记录里两种失败落成同一个 failed 状态,区别只藏在错误文本里;而目录不存在又常常不是这次改动造成的,可能是早一步的清理、并行的一次运行、一次移动或重命名把引用悬空了。对着这次的 diff 调试,方向从第一步就错了。
这类报错要当成"前提声明"来读,修复有固定的顺序:
1. 先分清对象:错误命名的是"必须存在的东西",不是"代码做错了什么"。命名了一个前提的失败,在前提改变之前,每次重跑都会一字不差地复现——它是一张工单,不是一次抖动,重试只会烧掉时间。 2. 在使用的那一刻验证状态,而不是在交接时假设:目录还在吗?还在你以为的那个位置吗?早一步准备好的工作区是一个会腐烂的假设——等待、清理、重试、并行的任务,任何一个都能在"准备好"和"被使用"之间把它移走或重塑。 3. 自己把声明和实物接上:要么补齐目录里本该有的真实文件,要么修正引用的指向;并且两个方向都查——每条被引用的路径都应该存在,写下的每个文件也应该被某条引用够到,缺的那一半在验证不看的方向上是静默的。 4. 只重跑检查本身,不要因为一条前提错误从头重跑整条链。 5. 统计时把"入场被拒"和"跑了且失败"分成两类。不分开的话,一阵一模一样的拒绝对外看起来就像连续失败的工作,把代码本身的真实信号埋掉——而这阵拒绝里没有一次真正评判过代码。
一分钟自检:挑你手上任何一个自动化入口,故意喂它一个不存在的路径跑一次,看这次的失败记录和你印象里一次真红灯能不能区分开。区分不开,说明你的失败统计里早就混着两类不同的东西——其中一类,从来不是代码的问题。