← 最新论文
💻 computer science

Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration

本实证研究分析了七个 Apache 项目中的 77,354 次持续集成构建失败,以量化开发者在不相关失败上浪费的开发精力,并证明利用持续集成延迟和错误模式等特征的半监督正例与未标记(PU)学习模型能够有效预测此类不可操作的失败,从而帮助开发者优先安排调试工作。

原作者: Andie Huang, Daniel Alencar da Costa, Grant Dick, Mariam El Mezouar

发布于 2026-05-08
📖 1 分钟阅读☕ 轻松阅读

原作者: Andie Huang, Daniel Alencar da Costa, Grant Dick, Mariam El Mezouar

原始论文采用 CC BY 4.0 许可(http://creativecommons.org/licenses/by/4.0/)。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性,请参阅原始论文。 阅读完整免责声明

想象你是一位在非常繁忙、混乱的厨房中工作的厨师(这就是持续集成环境)。每隔几分钟,就会有一道新订单进来(即一次代码提交),厨房会自动开始烹饪一道测试餐,以检查新食材是否适用。

有时,测试餐会烧焦或味道极差。通常,这意味着刚添加新食材的厨师犯了错误。但有时,火警响起是因为前一位厨师忘了关炉火,或者烤箱坏了,又或是隔壁房间有人打翻了托盘。这就是论文中所称的“无关构建失败”。

问题在于,刚添加新食材的厨师并不知道为什么这顿饭失败了。他们花费数小时(论文指出中位数为4 小时)疯狂地检查自己的香料和刀具,试图证明:“这不是我的错!”这浪费了大量时间并造成压力。

研究人员做了什么

作者(一个研究团队)决定调查这种厨房混乱。他们检查了来自 7 个大型开源软件项目(如 Apache Hadoop 和 HBase)的77,354次“烧焦的餐点”(构建失败)。

  1. 侦探工作:他们手动阅读了开发者在失败后留下的数千条评论。他们寻找诸如“这与我修改的内容无关”或“不相关”之类的短语。他们发现了约10,300个案例,开发者明确表示:“这次失败不是我的错。”
  2. 访谈:他们从中挑选了一个较小的、具有代表性的371个“不是我的错”案例样本,像侦探分析犯罪现场一样进行分析。他们问道:为什么开发者会说这不是他们的错?
    • 发现:最常见的原因包括:
      • 无关测试:失败的测试实际上是在检查厨房不同部分的内容,而非新食材。
      • 外部干扰:厨房之外的某些事物发生了变化(例如供应商向所有人交付了劣质面粉)。
      • 不可复现:火灾只发生了一次,但当他们尝试再次制作这顿饭时,一切正常(可能是随机的电源浪涌)。
      • “未说明”组:在**35%**的情况下,开发者只是说“不是我的错”,而没有解释原因。

解决方案:一位“智能助手”

由于开发者无法总是立即解释为什么某次失败是不相关的,研究人员构建了一个智能助手(一个机器学习模型)来替他们推测。

他们使用了一种称为PU 学习(正例 - 未标记学习)的特殊技术。

  • 类比:想象你正在教一只狗寻找特定类型的球。你有一些你知道是正确种类的球(正例)。但你还有一个巨大的混合球堆,你不知道其中哪些是正确的,哪些是错误的(未标记堆)。你不能简单地说“其他所有球都是错误的球”,因为其中一些实际上可能是正确的,只是你还没有检查过它们。
  • 工作原理:研究人员将“已知的无关失败”和“未知堆”输入模型。模型学会了识别暗示失败可能是不相关的模式,即使没有明确的标签。

这位助手表现如何?

该模型在同样的 7 个项目上进行了测试。

  • 它在精确率方面表现非常出色(当它说“这不是你的错”时,通常是对的,准确率约为 70% 到 88%)。
  • 它在召回率方面表现良好(它找到了大多数无关失败,尽管遗漏了一些)。
  • 它显著优于随机猜测或简单规则。

模型使用的“线索”

研究人员发现了三个主要线索,帮助模型判断失败是否无关:

  1. 时间间隔(CI 延迟):如果开发者提交了代码,并在触发构建前等待了很长时间,那么在此期间其他人搞砸了厨房的可能性就更大。
  2. “既视感”错误:如果错误信息与最近发生的一个错误完全相同,那么这很可能是旧问题的重复,而非当前厨师造成的新问题。
  3. 讨论热度:如果在失败发生之前该问题下有很多评论,这表明问题很复杂,可能涉及其他人的工作,而不仅仅是当前的提交。

核心结论

论文得出结论,通过使用这位“智能助手”,开发者可以获得一个快速提示:"这次失败很可能不是你的错。"

这并不意味着他们可以忽视问题,但这告诉他们:“不要花 4 小时检查你自己的代码。也许检查一下烤箱,或者问问其他厨师。”这有助于他们停止在误报上浪费时间,并更快地回到烹饪(编码)工作中。

重要提示:该论文完全专注于识别软件项目中的这些失败。它并未声称此方法适用于医疗诊断、金融交易或软件开发以外的任何其他领域。它严格是软件团队管理自身“厨房”混乱的工具。

您所在领域的论文太多了?

获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。

试用 Digest →