此页面由 Cloud Translation API 翻译。

封闭操作

目标与动力

在任何构建系统中定义构建操作时，请务必正确且完整地指定该操作的输入和输出。增量 build（对源代码进行细微更改之后的部分重新构建）依赖 build 图中的正确信息来正确识别和执行重新构建。如果此信息不正确或不完整，重新构建可能会产生错误的结果，或者产生与完整干净 build 不同的结果。

仅从其声明的输入读取且仅写入其声明的输出的操作对构建系统而言是封闭的。目前，我们还没有一个完全封闭的 build，而是有数十种操作和工具，可以读取/写入不在其声明的输入/输出中的文件。这使我们不再完全依赖于生产环境中的增量重新构建，迫使我们进行完全整洁的构建，而速度要慢大约 10 倍。

此外，这些非封闭操作往往表现为构建系统的不连贯行为，工程师遇到这种情况会浪费他们的时间进行问题排查。

此项目的目标是调查并修复 build 图中所有非封闭构建操作的实例。

熟悉 GN 和 BUILD.gn 文件非常重要，尤其是对于以下目标类型：

在许多情况下，您还需要了解 depfile 的工作原理：

您可以在本指南中找到其他重要信息：

选择任何标记为非封闭的构建目标。它们如下所示：

action("foo") {
  ...
  # TODO(https://fxbug.dev/xxxxx): delete the line below and fix this
  hermetic_deps = false
}

为了解某个操作为何是非封闭的，您需要在构建操作时启用操作跟踪工具。该工具会在跟踪其文件系统访问的同时运行所有构建操作，然后将这些访问与这些操作的已声明输入 / 输出 / depfile 进行比较。

如需在本地重现问题，请先移除 hermetic_deps = false，然后按如下所示设置 build：

fx set what --args=build_should_trace_actions=true

使用上述设置运行 build 时，应该会生成错误，其中包含可操作的问题排查信息。

默认情况下，CQ 会运行操作跟踪，因此您可以使用 CQ 获取相同的问题排查信息。

如果已针对相应问题提交 bug，则 bug 应包含错误中的信息。如果没有错误，请提交错误并记录您收集的信息。

有几种常见原因会导致封闭性问题。您可以在本指南中找到其中的部分选项。如果您遇到本指南未涵盖的问题，请考虑改进指南。

如果您能够移除 hermetic_deps = false，并且仍然通过跟踪或所跟踪的 tryjob 在本地成功构建，则表示您的更改已可接受审核。