在 WORKSPACE 规则中查找非封闭行为

报告问题 查看源代码 每夜 build · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

在下文中，主机是运行 Bazel 的机器。

使用远程执行时，实际的构建和/或测试步骤不会在主机上执行，而是发送到远程执行系统。不过，解析 Workspace 规则所涉及的步骤是在主机上执行的。如果您的 Workspace 规则访问主机相关信息以供在执行期间使用，则由于环境之间不兼容，您的 build 可能会中断。

在调整 Bazel 规则以进行远程执行的过程中，您需要找到此类工作区规则并进行修复。本页介绍了如何使用工作区日志查找可能存在问题的工作区规则。

查找非密封规则

工作区规则允许开发者向外部工作区添加依赖项，但其功能非常丰富，可允许在此过程中进行任意处理。所有相关命令都在本地执行，并且可能会造成非封闭。通常，非封闭行为是通过 repository_ctx 引入的，该函数允许与宿主机进行交互。

从 Bazel 0.18 开始，您可以通过向 Bazel 命令添加 --experimental_workspace_rules_log_file=[PATH] 标志来获取某些可能非密封操作的日志。其中 [PATH] 是用于创建日志的文件名。

需注意的事项：

  • 日志会在事件执行时捕获事件。如果某些步骤已缓存，则不会显示在日志中，因此，为了获取完整结果，请务必先运行 bazel clean --expunge。

  • 有时，系统可能会重新执行函数，在这种情况下，相关事件会在日志中显示多次。

  • Workspace 规则目前仅记录 Starlark 事件。

如需了解在工作区初始化期间执行了哪些操作，请执行以下操作：

  1. 运行 bazel clean --expunge。此命令将清除您的本地缓存和所有缓存的代码库，确保重新运行所有初始化。

  2. 将 --experimental_workspace_rules_log_file=/tmp/workspacelog 添加到 Bazel 命令并运行 build。

    这会生成一个二进制 proto 文件，其中列出了类型为 WorkspaceEvent 的消息

  3. 下载 Bazel 源代码，然后使用以下命令导航到 Bazel 文件夹。您需要源代码才能使用 workspacelog 解析器解析 Workspace 日志。

    git clone https://github.com/bazelbuild/bazel.git
cd bazel

  4. 在 Bazel 源代码库中，将整个工作区日志转换为文本。

    bazel build src/tools/workspacelog:parser
bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog > /tmp/workspacelog.txt

  5. 输出可能非常详细，并包含内置 Bazel 规则的输出。

    如需从输出中排除特定规则，请使用 --exclude_rule 选项。例如：

    bazel build src/tools/workspacelog:parser
bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog \
    --exclude_rule "//external:local_config_cc" \
    --exclude_rule "//external:dep" > /tmp/workspacelog.txt

  6. 打开 /tmp/workspacelog.txt 并检查是否存在不安全的操作。

该日志由 WorkspaceEvent 消息组成，其中概述了对 repository_ctx 执行的某些可能非密封的操作。

被突出显示为可能非封闭型操作的操作如下：

  • execute：在主机环境中执行任意命令。检查这些内容是否可能会在宿主环境中引入任何依赖项。

  • download、download_and_extract：为确保密封 build，请务必指定 sha256

  • file、template：这本身并不非密封，但可能是一种将对主机环境的依赖项引入到代码库中的机制。确保您了解输入的来源，并且它不依赖于宿主环境。

  • os：这本身并不非容器化，但是一种获取宿主环境依赖项的简单方法。封闭式 build 通常不会调用此方法。在评估使用情况是否封闭时，请注意，这是在主机上运行，而不是在工作器上运行。对于远程构建，通常不适合从主机获取环境详情。

  • symlink：这通常是安全的，但要留意危险信号。指向代码库外部或绝对路径的任何符号链接都会导致远程工作器出现问题。如果符号链接是基于宿主机属性创建的，也可能有问题。

  • which：检查主机上安装的程序通常会出现问题，因为工作器可能具有不同的配置。