一句话:提出基于构建日志文本相似度的语言无关棕色构建早期检测方法,并在工业项目上验证。
论文关注持续集成中因构建脚本问题或“flaky tests”导致的棕色构建(brown builds)——这些失败是假阳性,不代表源码质量,却耗费团队解读、重跑构建并拖慢集成流水线。作者原型化并评估早期检测方法:将新构建日志与既往棕色构建日志进行文本相似度比较,预测其是否为棕色构建。在 7 个项目(6 个工业闭源项目与开源 Graphviz)上评估。模型平均 F1 达 53%,约为最佳基线的三倍,至少与人类专家相当但成本更低;跨项目预测可用于项目导入期,30 周训练集效果最佳,重训练启发式仅每 4–5 周重训即可保持高于基线的 F1。
In principle, continuous integration (CI) practices allow modern software organizations to build and test their products after each code change to detect quality issues as soon as possible. In reality, issues with the build scripts (e.g., missing dependencies) and/or the presence of "flaky tests" lead to build failures that essentially are false positives, not indicative of actual quality problems of the source code. For our industrial partner, which is active in the video game industry, such "brown builds" not only require multidisciplinary teams to spend more effort interpreting or even re-running the build, leading to substantial redundant build activity, but also slows down the integration pipeline. Hence, this paper aims to prototype and evaluate approaches for early detection of brown build results based on textual similarity to build logs of prior brown builds. The approach is tested on 7 projects (6 closed-source from our industrial collaborators and 1 open-source, Graphviz). We find that our model manages to detect brown builds with a mean F1-score of 53% on the studied projects, which is three times more than the best baseline considered, and at least as good as human experts (but with less effort). Furthermore, we found that cross-project prediction can be used for a project's onboarding phase, that a training set of 30-weeks works best, and that our retraining heuristics keep the F1-score higher than the baseline, while retraining only every 4--5 weeks.