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.

翻译：代码评审是一种常见的实践，开发者在此过程中相互评审彼此的变更。由于自动化构建能够识别低层次问题（如语法错误、回归缺陷），软件组织在代码评审流程中纳入自动化构建的情况并不罕见。在这种代码评审部署场景中，提交的变更集必须同时通过同行代码评审者和自动化构建机器的审批才能被集成。由于自动化构建可能产生关于变更集状态的不可靠信号（例如，因“不稳定”或非确定性执行行为），像Gerrit这样的代码评审工具允许开发者请求“重新检查”，该操作会在不更新变更集的情况下重复构建过程。我们推测，如果“重新检查”命令的使用不够审慎，未加约束地将导致时间和资源的浪费。为了探究“重新检查”命令在实际环境中的应用情况，本文对OpenStack社区的66,932次代码评审进行了实证研究。我们定量分析了：（i）构建失败被重新检查的频率；（ii）触发重新检查改变构建失败结果的程度；以及（iii）触发重新检查所导致的资源浪费。我们观察到：（i）55%的代码评审在报告构建失败后调用了“重新检查”命令；（ii）调用该命令仅在42%的案例中改变了构建失败的结果；（iii）调用该命令使评审等待时间平均增加2200%，相当于187.4计算年的浪费——其计算资源足以与地球上最长寿的陆地动物相抗衡。