RFC-0095 - 在树外构建和组装工作站

RFC-0095：树外构建和组建工作站
状态已接受
领域
  • 常规
说明

创建一个工作流，允许用户在 fuchsia.git 之外构建和组装工作站产品。
Gerrit 更改
作者
审核人
提交日期（年-月-日）2021-03-24
审核日期（年-月-日）2021-05-19

修改此 RFC

修改 RFC 元数据

摘要

注意：此 RFC 已被 RFC-0220 取代，后者已弃用 工作站产品。我们会保留该 RFC 以供日后使用，但不会 实施时间更长。

Workstation 产品，定义为 station_session、ermine、Terminal 和简单的浏览器，目前是在 Fuchsia 源代码树中构建和组装的。 Fuchsia 平台和工作站没有明确区分 产品。这就要求平台和产品必须在 组装成品。我们提议断开此耦合， 允许将工作站组件与平台分开构建， 最终产品需在 Fuchsia 源代码树之外进行组装。这个 方案未涉及从 Fuchsia 源代码树，但侧重于树外的依赖问题 产品配置和组装这项工作将为 最终将工作站产品完全移出树状结构， 本文档未做详细介绍。

需要指出的是，终端被视为 组件，但其他工作站会使用该终端 Workstation 产品之外的产品。因此， 终端组件将保留在 fuchsia.git 中，并且将由 在做出与平台相关的进一步决定之前，作为平台的一部分 该组件的未来。

设计初衷

当前没有办法在 Fuchsia 上制造和组装产品， 同时构建整个 Fuchsia 平台。我们可以构建 包含 fuchsia.git 以外的组件，但这些工件需要顺畅运行 然后把它们放回 Fuchsia 全球集成，以便组装成最终成品。周三 希望能够为产品提供稳定版本的平台， 无需访问 Fuchsia Global Integration 即可构建。

在树外构建产品方面，仍有许多未知问题 这就是我们想要从 Workstation 产品入手的原因。工作站 产品并非面向用户的生产级产品， 为开发者提供参考资料以及为早期采用平台的环境提供参考信息 因此，对于在这个阶段运行速度缓慢的路段，有更高的容忍度 阶段。工作站产品也是一个 爱好者可以探索 Fuchsia；无需构建完整的 我们可以让开发者更轻松地玩 Fuchsia。

设计

基于独立映像组件将工作站移出 工具 RFC-0072 该方案假定此工具存在

代码库

工作站代码库的源代码将托管在 git-on-borg。将代码托管在 git-on-borg 上 我们可以使用现有的 Fuchsia 基础架构和工具， 专注于构建和组装产品的任务。

在本文档的其余部分中，station.git 将引用代码库 托管 Workstation 产品代码。

基础架构

此项目的重点是构建和组装工作站产品 因此我们不会将组件的开发工作移出 直到我们弄清楚如何操作为止由于该组件 开发仍然在树中，我们可以依赖现有的测试和构建 基础设施验证工作站产品不会退化。通过 更新平台、sdk、experience.git 和其他 依赖项，并使用脚本手动完成，让团队可以专注于 当前的问题当我们开始向 我们需要重新思考如何进行持续集成。

平台的每日构建需要实现自动化，但可以使用 现有的 Fuchsia 基础架构。需要创建一个每日构建器 构建组装工作站产品所需的软件包，并上传这些软件包 部署到某个存储区此工作流的技术设计仍然 需要解决的问题在此之前，我们会咨询基础架构和安全方面的问题 我们便开始着手处理这个问题

相对于核心产品，构建工作站产品可以确保 组装产品所需的全部工件 。我们在树外构建的工件 与平台相关的工件这样，我们还可以 使用现有的 Workstation Builder， 需要管理的基础架构

依赖项管理

Workstation 代码库将使用 Git 子模块和 Bazel 的组合 用于管理依赖项的工作区。Git 子模块将用于从外部拉取 而 Bazel 将用于下载预构建版本和工具链 所需的资源

Bazel 的工具链 与工作区规则结合使用，以下载相应的预构建版本 各构建规则所需的资源此时，一个限制是 我们的很多预构建版本都存储在 CIPD 中 并需要使用 cipd 命令行工具。初始原型要求 cipd 工具的位置。我们正在积极研究替代方案 不要认为这是一项长期要求

目录结构

工作站代码库的目录结构将与 fuchsia.git 目录结构，以便为 Fuchsia 开发者保持一致。通过 根目录将包含项目所需的各种元数据文件， 以及下列顶级目录

  • //src - 用于构建 Workstation 产品的源代码。
  • //tools - 用于支持构建的脚本和工具。
  • //src/experiences - 现有的 experiences.git 代码库。
  • //prebuilt - 任何需要的预构建版本。
  • //third_party - src 目录使用的第三方代码。

构建系统

Workstation 产品将使用 Bazel 构建 构建系统使用 Bazel 的决定不同于使用 fuchsia.git 的 gn/ninja。这一决定意味着，我们将无法依赖 或重复使用现有构建规则。不过， 当前的 gn SDK 不包含任何用于构建或测试 Flutter 的逻辑 是 Workstation 产品的大多数应用。该团队会 无论他们选择哪种构建系统，都需要编写这些规则。示例 树内存在的 Bazel SDK 有一些基本的构建逻辑， Dart 和 Flutter 应用。

Workstation 团队选择使用 Bazel 而非 gn/ninja 有几个主要原因 使此构建系统更易于使用。

  • 开源采用：Bazel 不是最受欢迎的构建系统， 比 gn/ninja 更多的采用率，因此对 开源社区。

  • 规则生态系统：Bazel 拥有丰富的现有规则生态系统， 提倡再利用

  • 依赖项管理：Bazel 可以管理外部依赖项。

  • Fuchsia SDK Bazel SDK 生产化：为工作站产品使用 Bazel 我们有机会将更改推送到 Fuchsia Bazel SDK， 其他项目使用的资源。

  • 单个构建/分析阶段：使用 Fuchsia 的开发者常见抱怨 他们不知道为什么他们的 build 中不包含某个软件包或工具。这个 这往往取决于用户未在 gn 参数中包含目标的情况。Bazel 移除 从而实现故障模式，要求用户明确指定 构建、运行或测试

  • 封闭构建：Bazel 默认具有封闭构建，而 gn 则没有。

在此阶段，我们需要编写构建规则来打造 针对 station.git buildroot 的代码库我们将利用 Bazel 的 new_local_repository 功能。使用此规则，我们可以 将 Bazel 专用构建规则保留到 worker 中，作为构建依据 映射的来源。请务必注意 此设置容易造成构建中断，因为 Bazel 构建规则 在与实际源代码不同的单独代码库中。这些损坏只会 会影响负责树外组装的团队， 树内开发者。我们知道这需要权衡，但最好还是 破坏树外开发者的工作流程，而不是树内开发者的工作流程 开发者。树外开发者将负责修复 保护服务。

//WORKSPACE

new_local_repository(
    name = "ermine",
    path = "vendor/experiences/session_shells/ermine/shell/",
    build_file = "src/ermine/BUILD.ermine",
)

//src/ermine/BUILD.ermine

flutter_component(name = "ermine_component", ...)
flutter_package(name = "ermine", deps = ":ermine_component")

语言支持

工作站组件目前是用 Dart 和 Rust 编写的，而 Dart 的 是目前唯一支持树外开发的语言。 station_session 和终端组件使用 Rust 和 Ermine 编写 和 simple-browser 都是使用 dart 编写的。首先，我们将注意力集中在 构建 Dart 组件，同时继续构建 Rust 组件 并将这些组件作为平台的一部分进行投放

目前，在构建 workspace_session 时存在两个障碍 非树状结构。第一个是工作站_session 使用 API，这意味着，即使我们拥有 语言支持。第二个阻碍是缺少树外 Rust 支持。 station_session 目前正在拆分为较小的平台级别 以消除对私有接口的依赖 我们正在探索对树外 Rust 的支持。我们会围绕 随着这两个项目的进展，工作站_session 的运行状态。如果 station_session 已完全从专用接口迁移到 Rust， 之后我们就不会用 C++ 重写会话了， 而如果 Rust 支持在 2024 年之前或之后不久，我们将保持会话 使用 Rust 编写而成

消毒用品

fuchsia.git 树支持各种排错程序，用于本地开发和 构建容器在工作站中支持这些系统。 存储库并不是近期的目标，因为我们不会将源代码移出 直到证明这个构建和组装系统可以 映射的代码库但是，我们应该阻止将代码移出 fuchsia.git 直到我们获得 Sanitizer 支持，因为这会从当前的 设置。

当本地 build 正常运行时，我们将添加对通过的 build 的支持 时间标志，以在本地启用各种排错程序。这样，我们便可以 与已启用排错程序的来源中的映射进行比较。当我们开始移动代码时 在 fuchsia.git 之外，我们将设置构建器以匹配当前 提交到 fuchsia.git

目前可以通过代码搜索搜索 Fuchsia 代码。 station.git 代码库将作为单独的项目添加到此项目中 让用户可以在线搜索和查看

代码覆盖率

我们不打算在 但短期内没有任何计划。导致这种情况的主要原因 大部分工作站代码都是用 Dart 编写的， 目前有足够的代码覆盖率支持，因此我们可以投入 启用所需时间

由于 它显示了代码覆盖率逐步提升，但要在 station.git 太大，目前无法使用。不过，它的存在 这是与 Fuchsia 构建团队合作的绝佳机会，可以让这些工具 轻松供树外开发者使用。

第三方支持

使用工作站.git 编写的所有源代码将需要共享相同的 第三方库支持这一点的工具已经问及了很多次 在其他大型代码库中进行托管，因此不必从头开始， 它确实代表了我们必须做大量的工作，并为 整个项目。

许可合规性将与 Fuchsia 项目所使用的许可合规性一致。合规性 将由 作为引入这些依赖项的代码审核过程的一部分。

我们目前还没有关于检查许可和生成 在构建期间和代码检查期间的通知文件。我们需要研究 在 fuchsia.git 代码库中完成，并将该逻辑移植到此代码库中。

二进制文件大小监控

监控二进制文件的大小对于我们的 项目。Fuchsia 构建系统中提供了一些工具，用于监控 每次提交期间生成的二进制文件列表再次构建这些系统 Workstation 产品不在此项目早期阶段的讨论范围内 但我们最终需要添加它。

我们需要调查这些系统与当前的 fuchsia.git 构建系统，看看我们能否直接将其集成到 或者我们需要采取措施来分离它们。如果需要处理 要将工具与构建系统分离开来，我们应该集中精力 可重复使用的工具，以便将来推广到其他产品集成商。

性能测试

目前，我们正在着手为 工作站产品。此项目已经在进行中，重点是 通过仅使用 公开 SDK 中提供的 API。我们计划将这些测试移至工作站。git 从 fuchsia.git 中移出。

所有者

最初为 workspace.git 代码库提供贡献者的人数不多 。因此， OWNERS 文件在此项目的初始阶段不会优先处理，但 我们会继续将其添加至相应的目录，以方便沟通。 随着我们开始将代码从 fuchsia.git 中移出，我们将会引入 OWNERS 文件并 对代码审核执行的规则与 fuchsia.git 中相同。

向 station.git 代码库贡献代码的行为也将受该代码库 对 fuchsia.git 的贡献内容的政策，因为这些内容将托管在 同一个项目。

错误跟踪

代码库将使用现有的 Fuchsia 问题跟踪器 来跟踪错误使用 Fuchsia 问题跟踪器的原因是它已经 之所以设置得是为了跟踪 Fuchsia 错误，而且是因为该工作站的开发板支持 产品仍将保留在 fuchsia.git 中。有一个顶级工作站组件 可用于一般分类。 用于跟踪 Workstation 产品的各种功能。

制品流程

要在 fuchsia.git 之外组装工作站产品，我们需要 提供要供工作站使用的 Fuchsia 平台的预构建版本 产品。这意味着我们将有两类工件， 以及叠加在平台之上的工件 组装最终的工作站产品映像。将构建平台映像 供工作站.git 代码库使用，而 工作站组件将在最终产品映像创建完成时构建， 组合起来构成平台的一系列工件未明确说明 平台正在不断演变，但工作站 组件将包括 station_session、Ermine 和 simple-browser。它 请注意，我们并不提议将任何驱动程序开发任务移出 即使它是一个仅支持 工作站产品。

如需允许 station.git 使用预构建的工件，我们需要设置 启动 fuchsia.git 的构建器以创建预构建的 和 Autoroller 将工件拉取到工作站.git我们可能会延长 但我们还没全面研究 如果可以的话

fuchsia.git 构建器每天运行一次，用于构建 Fuchsia 平台。 目前还不确定该构建器的具体配置方式， 您需要准确了解构建的内容构建工具会上传所有 适当的工件移到 Autoroller 可以使用的位置。确切的 上传这些制品的位置和机制尚未确定。 工件中将包含包含所有依赖项的清单文件 创建平台时使用的版本这包括但不限于 Experience.git 的版本、Flutter 和 Dart 版本、 Fuchsia 工具链版本等。

Autoroller 每天会运行多次，以检查是否有新版本的 平台。多次运行可以确保我们获取最新的 无论发布阶段不稳定，还是版本不同 在一整天中。Autoroller 将轮询该平台的最新版本 并拉取这些工件滚轮也会读取清单文件 包含所有依赖版本，并同时更新这些版本。这样可以确保 确保平台与各种依赖项之间不存在版本偏差。

所需的数据主要是包含文件系统分区的文件，例如 fuchsia.zbi 和 fvm.sparse.blk。这些文件包含启动、 以及“基本”和“缓存”列表中的所有软件包。这些文件将被 存储在 .far 的“product package”中，而位于 该软件包将包含构建组件软件包所需的所有元数据 匹配的 SDK。根据此元数据构建的软件包可以附加到基础和 修改“产品包”中包含的系统分区，以对缓存进行缓存。 此外，我们还要创建独立的树外图像汇编程序，因此 捆绑在“产品包”中的特定工件的列表是 可能因新工具的 API 而异。

每日构建器会以某种方式上传工件 访问“产品包”由指定版本生成。固定的代码库将包含 对平台的所有版本进行引用，使滚轮能够识别 最新 build 或适合 ABI 兼容性的特定 build。使用 而能够实现这一目标的流程目前， 提案。

在组装最终产品时，构建系统应首先下载 “product package”，通过网址标识然后，它会下载 SDK。（SDK 也可以捆绑在“产品包”中）。它应该 针对该 SDK 构建软件包，并为每个软件包创建一个 meta.far 文件，例如 并将所有必要的 blob 收集到一个位置。组装工具 然后将这些 blob 和 package 附加到“product package”，从而： 已完成的产品构建。生成的工件还应具备 以便生成 OTA 软件包。

ABI 注意事项

将工作站产品与平台分开编译可让我们 潜在的 ABI 不兼容问题。我们需要确保 使用符合以下条件的 SDK 发布版本编译工作站组件： 等于或早于，但每个版本的兼容窗口期内 RFC-0002、 工作站产品目前使用的平台的发布版本 为了确保这种不变性， 在元数据中添加 SDK 版本，该 SDK 版本将与平台和 station.git 代码库将更新，以使用此版本的 SDK。

请注意，这项 ABI 注意事项需要扩展到 为 Workstation 产品（如 Flutter 和 Dart 运行程序。为了最大限度地降低因这些花瓣而损坏 ABI 的风险， 最初会将它们作为平台的一部分发布，这意味着它们 已在 Fuchsia 的全球集成中得到验证。

当我们开始将花瓣从平台表面移开时 以确保它们与我们的产品兼容适合恢复至紫红色的花瓣 我们可以在构建 平台本身不过，将来我们的一些依赖项 进入 Fuchsia 全球集成，这意味着我们将没有版本信息， 包含在平台掷骰子中。我们需要使用平台版本控制 我们需要找到一种方法来 处理过时的版本。

实现

使用 fuchsia.git 构建和组装工作站产品的流程 将分为几个阶段，每个阶段都建立在 上一个。这种分阶段方法必不可少，因为 目前正在进行树外开发支持。

第 1 阶段

使工作站构建树外结构的初始阶段是 开发环境我们将创建 workspace.git 代码库来托管代码。 此代码库将包含引导脚本 以便用户快速上手代码库将使用 Bazel 工作区 和 Git 子模块，用于管理第三方代码、预构建版本和 体验代码库。

第 2 阶段

第二阶段的重点是设置构建系统以构建 Flutter 组件。我们将使用 fuchsia.git 中的现有 Bazel 规则 作为起点来编写构建规则当我们可以 成功构建一个 Flutter 组件，该组件可在已运行的 设备。

在设置 Flutter 组件构建规则的同时， 将探讨如何使用产品组装工具在树外组装。 此过程将手动完成，只需复制 将 fuchsia.git 构建到工作站.git 代码库的 out 目录中，并尝试 来创建可启动映像当我们可以为某台设备配置 非树外组装而内建的图像。

第 3 阶段

这一转变过程的第三阶段是，我们要努力实现上述所有目标， 将多个片段组合在一起，便构成了整套产品。这包括设置所有 构建平台工件并将其上传到 TUF 代码库。此构建器将在 Fuchsia 中运行 基础架构station.git 代码库将使用 autoroller。Autoroller 将更新工作站中的清单文件。 运行集成测试并提交此更改。这不同于 fuchsia.git：用于将版本更新提交到集成代码库 坐标版本更改。

构建和组装工作流将如下所示：

  1. 通过更新清单条目来发布新版本的平台 用于标识平台版本和所有从属版本。如何查看版本 读取和识别的需求。
  2. 使用 Bazel 和 git 下载相应的预构建代码库和第三方代码库 构建树内组件所需的资源。
  3. 使用平台下载工具从 TUF 存储区。
  4. 构建树内组件。
  5. 将构建的组件和预构建的组件组装到最终映像中。

性能

此项目应该不会对工作站的性能产生任何影响 因为它只负责制作和组装不过，我们应该开始 Workstation 开发者的构建时间显著缩短， 也不需要构建平台

安全注意事项

我们重复使用了 fuchsia.git 所用的大部分基础设施，但我们需要 ，确保以安全的方式构建和发布 Workstation。我们将 与安全和基础架构团队合作创建安全版本 和构建流水线。

工作站产品仅作为参考产品，但我们希望 以确保我们仍然遵循正确的安全协议。当我们 因此无论发布什么类型的内容 我们都需要与安全团队合作 我们以安全合规的方式构建应用

隐私注意事项

目前，隐私保护方面不会受到任何影响，有待考虑。我们将使用 不收集用户数据的工具

测试

Workstation 产品有一套针对每项提交运行的测试。这些 包括单元测试、集成测试、e2e 测试和性能测试。通过 这些测试的代码将作为 将工作站组件的代码移植到 workation.git 中。

这些测试的逻辑位于 Experience.git 中，以便我们能够运行它们 因为我们要将此代码库映射到工作站.git，直到我们 代码。所有这些测试都使用 因此我们可以在树外运行它们，但需要更新 以确保能在 fuchsia.git 之外进行构建和运行。

这些测试将在每次提交到工作站.git 代码库时运行，以防止 回归。这需要与基础架构团队协作， 了解如何在 CQ 中构建并运行这些测试。当前的基础架构假设 因为 fuchsia.git 存在，所以我们需要开发一种方法，即构建系统 与代码库布局无关

文档

我们只需向 station.git 添加文档 如何针对开发设置代码库。工作站开发 仍位于树中，因此我们应继续将文档指向 工作流。

缺点、替代方案和未知问题

另一种方法是在紫红树内完成所有这些工作 使用完全存在于 SDK 中的工具。我们已不再使用 因为这很容易隐藏我们对私有接口的使用情况。正在移动 这种组装完全离群值，迫使我们只能依赖 SDK。

对于需要上传到 TUF 的确切内容，仍有一些未知的因素 上传文件的形态以及 并上传相应的工件我们认为，这些具体细节将在 开始逐步完成相关流程，我们会根据需要修改此 RFC。