一句话:通过 66,932 条 OpenStack 代码审查记录,揭示 recheck 命令被频繁使用但常无效且造成大量计算浪费。
在代码审查中集成自动构建后,变更需同时获得评审者和构建机器人批准。由于构建可能因 flaky 或非确定性执行产生不可靠信号,Gerrit 等工具允许开发者触发 recheck 重复构建而不更新变更集。本文对 OpenStack 社区 66,932 条代码审查进行实证分析,量化 recheck 的使用频率、对构建失败结果的影响及浪费。结果显示:55% 的代码审查在构建失败后调用 recheck;仅 42% 的失败构建经 recheck 后改变结果;recheck 使审查等待时间平均增加 2,200%,相当于 187.4 计算年的浪费。基于开发者调查与历史分析,作者建议审慎使用 recheck,并为减少浪费指明未来方向。
Code review is a popular practice where developers critique each others' changes. Since automated builds can identify low-level issues (e.g., syntactic errors, regression bugs), it is not uncommon for software organizations to incorporate automated builds in the code review process. In such code review deployment scenarios, submitted change sets must be approved for integration by both peer code reviewers and automated build bots. Since automated builds may produce an unreliable signal of the status of a change set (e.g., due to “flaky” or non-deterministic execution behaviour), code review tools, such as Gerrit, allow developers to request a “recheck”, which repeats the build process without updating the change set. We conjecture that an unconstrained recheck command will waste time and resources if it is not applied judiciously. To explore how the recheck command is applied in a practical setting, in this paper, we conduct an empirical study of 66,932 code reviews from the OpenStack community. We quantitatively analyze (i) how often build failures are rechecked; (ii) the extent to which invoking recheck changes build failure outcomes; and (iii) how much waste is generated by invoking recheck. We observe that (i) 55% of code reviews invoke the recheck command after a failing build is reported; (ii) invoking the recheck command only changes the outcome of a failing build in 42% of the cases; and (iii) invoking the recheck command increases review waiting time by an average of 2,200% and equates to 187.4 compute years of waste-enough compute resources to compete with the oldest land living animal on earth. Our observations indicate that the recheck command is frequently used after the builds fail, but does not achieve a high likelihood of build success. Based on a developer survey and our history-based quantitative findings, we encourage reviewer teams to think twice before rechecking and be considerate of waste. While recheck currently generates plenty of wasted computational resources and bloats waiting times, it also presents exciting future opportunities for researchers and tool builders to propose solutions that can reduce waste.
DOI 原文 · arXiv · PDF(开放获取) · DBLP
@inproceedings{abs-2308-10078,
title = {Repeated Builds During Code Review: An Empirical Study of the OpenStack Community},
author = {Rungroj Maipradit and Dong Wang and Patanamon Thongtanunam and Raula Gaikovina Kula and Yasutaka Kamei and Shane McIntosh},
booktitle = {ASE},
year = {2023},
doi = {10.1109/ase56229.2023.00030}
}