封闭

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

本页介绍了密封性、使用密封 build 的好处，以及用于在 build 中识别非密封行为的策略。

概览

给定相同的输入源代码和产品配置时，密封型构建系统会通过将构建与主机系统的更改隔离，始终返回相同的输出。

为了隔离 build，密封 build 对本地或远程主机上安装的库和其他软件不敏感。它们依赖于特定版本的构建工具（例如编译器）和依赖项（例如库）。这样一来，构建过程便是自包含的，因为它不依赖于构建环境之外的服务。

封闭的两个重要方面是：

  • 隔离：密封型构建系统会将工具视为源代码。它们会下载工具的副本，并在受管理的文件树中管理其存储和使用。这会在主机和本地用户之间创建隔离 包括已安装的语言版本。
  • 来源标识：密封型构建系统会尝试确保输入的一致性。代码库（例如 Git）使用唯一的哈希代码来识别一组代码变体。封闭式构建系统使用此哈希来识别对 build 的输入。

优势

密封型 build 的主要优势包括：

  • 速度：操作的输出可以缓存，除非输入发生变化，否则无需再次运行操作。
  • 并行执行：对于给定的输入和输出，构建系统可以构建所有操作的图表，以计算高效的并行执行。构建系统加载规则并计算操作图 对输入进行哈希处理，以便在缓存中查找。
  • 多个 build：您可以在同一项上构建多个封闭 build 每个机器都使用不同的工具和版本进行构建。
  • 可重现性：封闭 build 有助于排查问题，因为 了解生成相应 build 的确切条件。

识别非密封性

如果您准备改用 Bazel，请提前改进现有 build 的密封性，以便更轻松地进行迁移。一些常见的 build 中的非封闭性：

  • .mk 文件中的任意处理
  • 以非确定性方式创建文件的操作或工具，通常涉及 build ID 或时间戳
  • 不同主机不同的系统二进制文件（例如 /usr/bin 二进制文件、绝对二进制文件） 路径、用于原生 C++ 规则自动配置的系统 C++ 编译器）
  • 在构建期间向源代码树写入数据。这样可以防止与 不会用于另一个目标。第一个构建会向源代码写入数据 修复目标 A 的源代码树。然后尝试构建目标 B 失败。

排查非容器化 build 问题

从本地执行开始，影响本地缓存命中的各个问题都会揭示非密封操作。

  • 确保 null 顺序 build：如果您运行 make 并成功构建，再次运行 build 不应重新构建任何目标。如果运行每个 build 或者在不同系统上执行两次步，比较文件内容的哈希值，然后 获得不同的结果，构建不可重现。
  • 运行步骤 调试本地缓存命中 各种潜在的客户端机器，以确保您可以捕获 客户环境泄漏到行动中的情况。
  • 在 Docker 容器中执行构建，该容器中除了已检出的源代码树和主机工具的显式列表外，不包含任何其他内容。制造中断和 错误消息将捕获隐式系统依赖项。
  • 使用以下代码发现并修复密封问题 remote execution rules。
  • 请在每个操作级别启用严格的沙盒，因为 build 中的操作可能会具有状态，并会影响 build 或输出。
  • 工作区规则允许开发者向外部工作区添加依赖项，但它们足够丰富，可以在处理过程中执行任意处理。您可以 通过以下方法获取 Bazel 工作区规则中一些可能的非封闭操作的日志 添加国旗 --experimental_workspace_rules_log_file=PATH至 运行 Bazel 命令

使用 Bazel 实现密封性

有关其他项目如何使用封闭的成功的详细信息 使用 Bazel 构建，请参阅以下 BazelCon 讲座：