Rust 编译器 CI 中的 Fuchsia 集成测试构建流程、本地复现与调试实战【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust本指南以 rustc-dev-guide 中 Fuchsia integration tests 一章为核心系统讲解 Rust 编译器仓库如何将 Fuchsia 这一大型 Rust 代码库作为回归测试集成进 CI包括 bors 门禁中的触发方式、基于 Docker 的本地构建复现、fx/GN/Ninja 构建体系的关键操作以及出现故障时的处理路径。读完本文你将掌握在本地复现 Fuchsia 构建、定制构建参数、调试工具链回归的完整实战方法。Fuchsia 集成测试在 Rust CI 中的角色Fuchsia、wasi 等集成测试并列。在仓库中Fuchsia 集成任务的入口位于 src/ci/github-actions/jobs.yml其定义的任务名即x86_64-fuchsia。需要说明的是当前仓库中该任务处于注释禁用状态原因正如文件内注释所述# FIXME: temporarily disabled due to fuchsia server rate limits. See # https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/fuchsia.20failure/with/506637259. #- name: x86_64-fuchsia即曾因 Fuchsia 服务器速率限制rate limits而临时关闭。这意味着你在复现或研究该任务时应以本地 Docker 构建路径为准并留意 CI 配置可能与文档描述存在时间差。当 Fuchsia 任务挂掉时该找谁Fuchsia 集成测试涉及编译器、标准库与 Fuchsia 三方代码的联动一旦失败往往需要 Fuchsia 团队协助判断根因。rustc-dev-guide 给出的标准做法是使用 rustbot ping 对应的通知组rustbot ping fuchsiafuchsiaping 组的定义见 notification-groups/fuchsia.md它对应 GitHub 标签O-fuchsia当编译器或标准库的改动可能破坏 Fuchsia 集成时该组成员会收到通知。因此遇到任务失败先 ping 该组请求协助是文档推荐的第一个动作。在 CI 中构建 FuchsiaFuchsia 构建作为 bors 测试套件suite of bors tests的一部分运行即任何 PR 在合并前都会经过这一关。如果你担心某个 PR 可能破坏 Fuchsia 构建器希望在提交到 bors 队列之前先行验证可以直接请求 bors 运行只构建 Fuchsia 集成的 try jobbors try jobsx86_64-fuchsiatry job 是 bors 提供的预检机制允许 PR 作者在正式合并前用与 CI 完全相同的任务定义做一次试运行从而在不占用合并队列的情况下提前暴露问题。本地构建 Fuchsia为什么不能直接用 CargoFuchsia 的构建体系与纯 Rust 项目有本质差异由于它使用 Rust 之外的多门语言C/C 等并不采用 Cargo 作为构建系统同时它要求 rustc 工具链以特定方式配置例如必须使用 LLVM 后端、特定 sysroot 与链接参数。文档明确提示Fuchsia 官方提供了工具链构建的特定配置要求因此本地复现必须遵循仓库中现成的脚本路径而非简单的cargo build。推荐方式Docker 脚本一键构建rustc-dev-guide 推荐的本地构建方式是使用 Docker 脚本它会自动完成 Fuchsia 的检出与构建。如果你此前运行过 Docker 测试只需在 Rust 检出目录下执行src/ci/docker/run.sh x86_64-fuchsia该命令会基于你本地的 Rust 工具链下载并构建 Fuchsia。关于run.sh的工作原理如何构建 Docker 镜像、以只读方式挂载源码树、将构建产物写入obj目录等详见 Testing with Docker 一章——其中也提到了交互式模式src/ci/docker/run.sh --dev image-name可进入容器手工执行命令这对调试 Fuchsia 任务尤其有用。需要注意资源开销一次 Fuchsia 的检出加构建约需46G 磁盘空间且耗时较长请预留充足资源。从源码看 Docker 构建的完整链路仓库中实际的构建脚本位于 src/ci/docker/host-x86_64/test-x86_64-fuchsia/build-fuchsia.sh其头部注释给出了两种运行方式# 方式一直接通过 run.sh 构建 $ src/ci/docker/run.sh x86_64-fuchsia # 方式二进入容器--dev 模式后手动执行 $ src/ci/docker/run.sh --dev x86_64-fuchsia docker# git config --global --add safe.directory /checkout/obj/fuchsia docker# ../src/ci/docker/host-x86_64/x86_64-fuchsia/build-fuchsia.sh对应的 Docker 镜像定义在 test-x86_64-fuchsia/Dockerfile基于ubuntu:22.04。从该文件可以还原 CI 中 Fuchsia 任务的两阶段流程先通过x.py install构建出能编译 Fuchsia 的工具链再运行build-fuchsia.sh完成 Fuchsia 集成构建ENV SCRIPTpython3 ../x.py install --target $TARGETS compiler/rustc library/std clippy \ bash ../src/ci/docker/host-x86_64/x86_64-fuchsia/build-fuchsia.sh其中TARGETSx86_64-unknown-fuchsia,x86_64-unknown-linux-gnu。镜像还预先设定了若干关键环境约束值得留意CODEGEN_BACKENDSllvmFuchsia 只支持 LLVM 后端NO_DOWNLOAD_CI_RUSTC1x install不允许下载 CI 预编译的 rustcCARGO_TARGET_X86_64_UNKNOWN_FUCHSIA_RUSTFLAGS包含-C panicabort、-C force-unwind-tablesyes、sysroot 链接参数等RUST_CONFIGURE_ARGS指定 target 的cc/cxx/ar/ranlib/linker均指向 clang/LLVM 工具链。工具链前置依赖Fuchsia SDK 与 Clang 的下载、校验、软链由 scripts/build-fuchsia-toolchain.sh 完成它从 Chrome Infra Packages 下载固定版本SDKversion:26.20241211.7.1、clanggit_revision:388d7f14...并用 SHA256 校验。修改 Fuchsia 检出KEEP_CHECKOUT本地构建 Fuchsia 的主要动机通常是调查回归。Docker 构建完成后Fuchsia 检出位于 Rust 检出目录下的obj/fuchsiabuild-fuchsia.sh 脚本头部注释则写为obj/x86_64-fuchsia/fuchsia两个路径在不同时期/上下文中的表述略有差异以实际生成的目录为准。如果需要改动检出内容并复用之前的构建结果把 build-fuchsia.sh 中的KEEP_CHECKOUT设为1# 设置为 1 时禁用 Fuchsia 检出的更新便于本地修改 KEEP_CHECKOUT改成KEEP_CHECKOUT1后重新运行上文构建命令即可复用全部既有构建产物只在你修改的部分之上增量构建。该脚本还暴露了另外两个可定制点PICK_REFS可填入来自 fxrev.devGerrit的 cherry-pick ref用于在开发中纳入未合入的 Fuchsia 变更例如PICK_REFS(refs/changes/71/1054071/2 refs/changes/74/1054574/2)INTEGRATION_SHA固定 Fuchsiaintegration.git的 commit hash它同时决定了 fuchsia.git 等 monorepo 仓库的 commit 与预编译产物版本由 Fuchsia 团队定期目标每 12 个月更新。脚本的执行流程本身也清晰可读先用curl引导下载jiri工具随后jiri init -partialtrue初始化、jiri import -revision$INTEGRATION_SHA导入 integration 清单、jiri update同步各仓库最后执行bash scripts/rust/build_fuchsia_from_rust_ci.sh即把后续构建交给 Fuchsia 检出内部的脚本完成。定制 Fuchsia 构建Rust CI 中用于构建 Fuchsia 的具体参数定义在由build-fuchsia.sh调用的build_fuchsia_from_rust_ci.sh位于 Fuchsia 检出的scripts/rust/下中你可以通过KEEP_CHECKOUT1修改该脚本中的参数来定制构建。从构建体系角度理解Fuchsia 的构建系统基于GN——一个生成 Ninja 文件的元构建系统metabuild system生成完成后把实际构建工作交给 Ninja 执行。Fuchsia 开发者日常使用fx工具驱动构建与开发任务它位于检出的.jiri_root/bin目录下某些工作流可能需要将该目录加入$PATH。与 Rust CI 相关的fx子命令有三个子命令作用说明fx set接受构建参数写入out/default/args.gn并运行 GN相当于配置阶段fx build用 Ninja 构建 Fuchsia 项目自动感知构建参数变化并重跑 GN默认构建全部也接受指定 target 路径fx clippy对指定或全部Rust target 运行 ClippyRust CI 用它避免对大多数 Rust target 做 codegen底层同样调用 Ninjaclippy 结果以 json 文件保存在构建输出目录中再打印GN 目标路径Target paths语法GN 用如下形式标识构建目标//src/starnix/kernel:starnix_core开头的//表示检出根目录其余斜杠为目录名:之后的字符串是该目录BUILD.gn文件中定义的目标名target name。目标名在与目录名相同时可以省略即//src/starnix/kernel等价于//src/starnix/kernel:kernel。这类目标路径既用于BUILD.gn内声明依赖也可直接传给fx build构建特定目标。修改编译器 flags要为某个 target 附加自定义编译器参数可以在 GNconfig中声明 rustflags再挂到目标上。文档给出如下示例config(everybody_loops) { rustflags [ -Zeverybody-loops ] } rustc_binary(example) { crate_root src/bin.rs # ...existing keys here... configs [ :everybody_loops ] }这会让 rustc 在构建example目标时带上-Zeverybody-loops标志。此外使用public_configs可将 config 传播给所有依赖该 target 的目标若想给构建中每个Rust target 都加标志可把 rustflags 加入 Fuchsia 的//build/config:compilerconfig或该文件引用的 OS 相关 config注意cflags与ldflags在 Rust 目标上会被忽略Rust 目标只认 rustflags 相关配置。直接运行 ninja 与 rustc再往下一层fx build实际调用ninja而ninja最终调用rustc。所有构建动作都在输出目录通常为 Fuchsia 检出内的out/default中执行。要拿到 ninja 实际执行的完整命令一个实用技巧是故意让命令失败例如给目标某个源文件加一个语法错误ninja 会打印它即将执行的编译命令拿到命令后即可从输出目录内手动运行便于加参数、加打印做排查。在修改了工具链本身之后out/default/args.gn中的构建设置rustc_version_string必须改动fx build或ninja才会重建全部 Rust 目标。该字符串的具体内容无关紧要只要与上一次构建不同即可其作用相当于一个版本标记触发 ninja 判定依赖失效。build_fuchsia_from_rust_ci.sh 会通过对工具链目录做哈希来自动完成这一步骤。Fuchsia 官网对构建系统有更详细的文档。其他技巧与建议使用build_fuchsia_from_rust_ci.sh时初次运行后可以把其中的fx set命令注释掉避免每次重跑 GN若这样做也可一并注释 version_string 行节省几秒钟export NINJA_PERSISTENT_MODE1可加快初次构建之后 ninja 的启动速度。Fuchsia 目标支持关于 Fuchsia 作为 Rust 编译目标如x86_64-unknown-fuchsia、aarch64-unknown-fuchsia的更多支持细节rustc-dev-guide 指向 rustc book 的 platform-support 一章Fuchsia 章节可在官方 rustc 文档中查阅。本仓库中与 Fuchsia 目标相关的代码分散于编译器 target 定义与上文所述的 CI 基建中需要深入研究目标 ABI、std 支持情况时可从 compiler/rustc_target 与 library/std 入手。附在模拟器上运行 Fuchsia 测试的基建除构建集成外仓库还提供了在 Fuchsia 模拟器上运行 Rust 测试套件的独立工具 src/ci/docker/scripts/fuchsia-test-runner.py。它定义了start/run/stop/cleanup/debug/syslog等子命令工作流程包括启动 ffx 隔离环境、下载 product bundle、拉起无头模拟器ffx emu start --headless、创建并注册包仓库ffx repository create/server start、把测试二进制连同 libstd/libtest 打成 Fuchsia 包CML 清单 ffx package build、发布后经ffx test run在模拟器上执行并解析run_summary.json判定 PASSED/失败。debug子命令还能通过 zxdb 连接模拟器调试指定测试用例。这套基建与build-fuchsia.sh构成互补前者验证工具链能构建 Fuchsia后者验证工具链产出的程序能在 Fuchsia 上正确运行。总结故障处理Fuchsia 任务失败时用rustbot ping fuchsia联系 fuchsia 通知组CI 预检bors try jobsx86_64-fuchsia可在合并前验证 PR 是否破坏 Fuchsia 构建器本地复现src/ci/docker/run.sh x86_64-fuchsia一键构建注意 46G 磁盘与耗时相关脚本与镜像定义分别位于 build-fuchsia.sh 和 Dockerfile回归调查置KEEP_CHECKOUT1复用检出与构建产物通过 GN config 注入 rustflags、修改rustc_version_string触发全量重建、强制 ninja 失败以捕获实际 rustc 命令目标支持Fuchsia target 的正式支持说明见 rustc book 的 platform-support 章节。将 Fuchsia 集成测试跑通等于拿到了一个约 200 万行 Rust 代码的真实大型编译器消费者作为回归验证环境——这正是 rustc-dev-guide 将其纳入生态测试任务的核心价值所在。【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Rust 编译器 CI 中的 Fuchsia 集成测试：构建流程、本地复现与调试实战
Rust 编译器 CI 中的 Fuchsia 集成测试构建流程、本地复现与调试实战【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust本指南以 rustc-dev-guide 中 Fuchsia integration tests 一章为核心系统讲解 Rust 编译器仓库如何将 Fuchsia 这一大型 Rust 代码库作为回归测试集成进 CI包括 bors 门禁中的触发方式、基于 Docker 的本地构建复现、fx/GN/Ninja 构建体系的关键操作以及出现故障时的处理路径。读完本文你将掌握在本地复现 Fuchsia 构建、定制构建参数、调试工具链回归的完整实战方法。Fuchsia 集成测试在 Rust CI 中的角色Fuchsia、wasi 等集成测试并列。在仓库中Fuchsia 集成任务的入口位于 src/ci/github-actions/jobs.yml其定义的任务名即x86_64-fuchsia。需要说明的是当前仓库中该任务处于注释禁用状态原因正如文件内注释所述# FIXME: temporarily disabled due to fuchsia server rate limits. See # https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/fuchsia.20failure/with/506637259. #- name: x86_64-fuchsia即曾因 Fuchsia 服务器速率限制rate limits而临时关闭。这意味着你在复现或研究该任务时应以本地 Docker 构建路径为准并留意 CI 配置可能与文档描述存在时间差。当 Fuchsia 任务挂掉时该找谁Fuchsia 集成测试涉及编译器、标准库与 Fuchsia 三方代码的联动一旦失败往往需要 Fuchsia 团队协助判断根因。rustc-dev-guide 给出的标准做法是使用 rustbot ping 对应的通知组rustbot ping fuchsiafuchsiaping 组的定义见 notification-groups/fuchsia.md它对应 GitHub 标签O-fuchsia当编译器或标准库的改动可能破坏 Fuchsia 集成时该组成员会收到通知。因此遇到任务失败先 ping 该组请求协助是文档推荐的第一个动作。在 CI 中构建 FuchsiaFuchsia 构建作为 bors 测试套件suite of bors tests的一部分运行即任何 PR 在合并前都会经过这一关。如果你担心某个 PR 可能破坏 Fuchsia 构建器希望在提交到 bors 队列之前先行验证可以直接请求 bors 运行只构建 Fuchsia 集成的 try jobbors try jobsx86_64-fuchsiatry job 是 bors 提供的预检机制允许 PR 作者在正式合并前用与 CI 完全相同的任务定义做一次试运行从而在不占用合并队列的情况下提前暴露问题。本地构建 Fuchsia为什么不能直接用 CargoFuchsia 的构建体系与纯 Rust 项目有本质差异由于它使用 Rust 之外的多门语言C/C 等并不采用 Cargo 作为构建系统同时它要求 rustc 工具链以特定方式配置例如必须使用 LLVM 后端、特定 sysroot 与链接参数。文档明确提示Fuchsia 官方提供了工具链构建的特定配置要求因此本地复现必须遵循仓库中现成的脚本路径而非简单的cargo build。推荐方式Docker 脚本一键构建rustc-dev-guide 推荐的本地构建方式是使用 Docker 脚本它会自动完成 Fuchsia 的检出与构建。如果你此前运行过 Docker 测试只需在 Rust 检出目录下执行src/ci/docker/run.sh x86_64-fuchsia该命令会基于你本地的 Rust 工具链下载并构建 Fuchsia。关于run.sh的工作原理如何构建 Docker 镜像、以只读方式挂载源码树、将构建产物写入obj目录等详见 Testing with Docker 一章——其中也提到了交互式模式src/ci/docker/run.sh --dev image-name可进入容器手工执行命令这对调试 Fuchsia 任务尤其有用。需要注意资源开销一次 Fuchsia 的检出加构建约需46G 磁盘空间且耗时较长请预留充足资源。从源码看 Docker 构建的完整链路仓库中实际的构建脚本位于 src/ci/docker/host-x86_64/test-x86_64-fuchsia/build-fuchsia.sh其头部注释给出了两种运行方式# 方式一直接通过 run.sh 构建 $ src/ci/docker/run.sh x86_64-fuchsia # 方式二进入容器--dev 模式后手动执行 $ src/ci/docker/run.sh --dev x86_64-fuchsia docker# git config --global --add safe.directory /checkout/obj/fuchsia docker# ../src/ci/docker/host-x86_64/x86_64-fuchsia/build-fuchsia.sh对应的 Docker 镜像定义在 test-x86_64-fuchsia/Dockerfile基于ubuntu:22.04。从该文件可以还原 CI 中 Fuchsia 任务的两阶段流程先通过x.py install构建出能编译 Fuchsia 的工具链再运行build-fuchsia.sh完成 Fuchsia 集成构建ENV SCRIPTpython3 ../x.py install --target $TARGETS compiler/rustc library/std clippy \ bash ../src/ci/docker/host-x86_64/x86_64-fuchsia/build-fuchsia.sh其中TARGETSx86_64-unknown-fuchsia,x86_64-unknown-linux-gnu。镜像还预先设定了若干关键环境约束值得留意CODEGEN_BACKENDSllvmFuchsia 只支持 LLVM 后端NO_DOWNLOAD_CI_RUSTC1x install不允许下载 CI 预编译的 rustcCARGO_TARGET_X86_64_UNKNOWN_FUCHSIA_RUSTFLAGS包含-C panicabort、-C force-unwind-tablesyes、sysroot 链接参数等RUST_CONFIGURE_ARGS指定 target 的cc/cxx/ar/ranlib/linker均指向 clang/LLVM 工具链。工具链前置依赖Fuchsia SDK 与 Clang 的下载、校验、软链由 scripts/build-fuchsia-toolchain.sh 完成它从 Chrome Infra Packages 下载固定版本SDKversion:26.20241211.7.1、clanggit_revision:388d7f14...并用 SHA256 校验。修改 Fuchsia 检出KEEP_CHECKOUT本地构建 Fuchsia 的主要动机通常是调查回归。Docker 构建完成后Fuchsia 检出位于 Rust 检出目录下的obj/fuchsiabuild-fuchsia.sh 脚本头部注释则写为obj/x86_64-fuchsia/fuchsia两个路径在不同时期/上下文中的表述略有差异以实际生成的目录为准。如果需要改动检出内容并复用之前的构建结果把 build-fuchsia.sh 中的KEEP_CHECKOUT设为1# 设置为 1 时禁用 Fuchsia 检出的更新便于本地修改 KEEP_CHECKOUT改成KEEP_CHECKOUT1后重新运行上文构建命令即可复用全部既有构建产物只在你修改的部分之上增量构建。该脚本还暴露了另外两个可定制点PICK_REFS可填入来自 fxrev.devGerrit的 cherry-pick ref用于在开发中纳入未合入的 Fuchsia 变更例如PICK_REFS(refs/changes/71/1054071/2 refs/changes/74/1054574/2)INTEGRATION_SHA固定 Fuchsiaintegration.git的 commit hash它同时决定了 fuchsia.git 等 monorepo 仓库的 commit 与预编译产物版本由 Fuchsia 团队定期目标每 12 个月更新。脚本的执行流程本身也清晰可读先用curl引导下载jiri工具随后jiri init -partialtrue初始化、jiri import -revision$INTEGRATION_SHA导入 integration 清单、jiri update同步各仓库最后执行bash scripts/rust/build_fuchsia_from_rust_ci.sh即把后续构建交给 Fuchsia 检出内部的脚本完成。定制 Fuchsia 构建Rust CI 中用于构建 Fuchsia 的具体参数定义在由build-fuchsia.sh调用的build_fuchsia_from_rust_ci.sh位于 Fuchsia 检出的scripts/rust/下中你可以通过KEEP_CHECKOUT1修改该脚本中的参数来定制构建。从构建体系角度理解Fuchsia 的构建系统基于GN——一个生成 Ninja 文件的元构建系统metabuild system生成完成后把实际构建工作交给 Ninja 执行。Fuchsia 开发者日常使用fx工具驱动构建与开发任务它位于检出的.jiri_root/bin目录下某些工作流可能需要将该目录加入$PATH。与 Rust CI 相关的fx子命令有三个子命令作用说明fx set接受构建参数写入out/default/args.gn并运行 GN相当于配置阶段fx build用 Ninja 构建 Fuchsia 项目自动感知构建参数变化并重跑 GN默认构建全部也接受指定 target 路径fx clippy对指定或全部Rust target 运行 ClippyRust CI 用它避免对大多数 Rust target 做 codegen底层同样调用 Ninjaclippy 结果以 json 文件保存在构建输出目录中再打印GN 目标路径Target paths语法GN 用如下形式标识构建目标//src/starnix/kernel:starnix_core开头的//表示检出根目录其余斜杠为目录名:之后的字符串是该目录BUILD.gn文件中定义的目标名target name。目标名在与目录名相同时可以省略即//src/starnix/kernel等价于//src/starnix/kernel:kernel。这类目标路径既用于BUILD.gn内声明依赖也可直接传给fx build构建特定目标。修改编译器 flags要为某个 target 附加自定义编译器参数可以在 GNconfig中声明 rustflags再挂到目标上。文档给出如下示例config(everybody_loops) { rustflags [ -Zeverybody-loops ] } rustc_binary(example) { crate_root src/bin.rs # ...existing keys here... configs [ :everybody_loops ] }这会让 rustc 在构建example目标时带上-Zeverybody-loops标志。此外使用public_configs可将 config 传播给所有依赖该 target 的目标若想给构建中每个Rust target 都加标志可把 rustflags 加入 Fuchsia 的//build/config:compilerconfig或该文件引用的 OS 相关 config注意cflags与ldflags在 Rust 目标上会被忽略Rust 目标只认 rustflags 相关配置。直接运行 ninja 与 rustc再往下一层fx build实际调用ninja而ninja最终调用rustc。所有构建动作都在输出目录通常为 Fuchsia 检出内的out/default中执行。要拿到 ninja 实际执行的完整命令一个实用技巧是故意让命令失败例如给目标某个源文件加一个语法错误ninja 会打印它即将执行的编译命令拿到命令后即可从输出目录内手动运行便于加参数、加打印做排查。在修改了工具链本身之后out/default/args.gn中的构建设置rustc_version_string必须改动fx build或ninja才会重建全部 Rust 目标。该字符串的具体内容无关紧要只要与上一次构建不同即可其作用相当于一个版本标记触发 ninja 判定依赖失效。build_fuchsia_from_rust_ci.sh 会通过对工具链目录做哈希来自动完成这一步骤。Fuchsia 官网对构建系统有更详细的文档。其他技巧与建议使用build_fuchsia_from_rust_ci.sh时初次运行后可以把其中的fx set命令注释掉避免每次重跑 GN若这样做也可一并注释 version_string 行节省几秒钟export NINJA_PERSISTENT_MODE1可加快初次构建之后 ninja 的启动速度。Fuchsia 目标支持关于 Fuchsia 作为 Rust 编译目标如x86_64-unknown-fuchsia、aarch64-unknown-fuchsia的更多支持细节rustc-dev-guide 指向 rustc book 的 platform-support 一章Fuchsia 章节可在官方 rustc 文档中查阅。本仓库中与 Fuchsia 目标相关的代码分散于编译器 target 定义与上文所述的 CI 基建中需要深入研究目标 ABI、std 支持情况时可从 compiler/rustc_target 与 library/std 入手。附在模拟器上运行 Fuchsia 测试的基建除构建集成外仓库还提供了在 Fuchsia 模拟器上运行 Rust 测试套件的独立工具 src/ci/docker/scripts/fuchsia-test-runner.py。它定义了start/run/stop/cleanup/debug/syslog等子命令工作流程包括启动 ffx 隔离环境、下载 product bundle、拉起无头模拟器ffx emu start --headless、创建并注册包仓库ffx repository create/server start、把测试二进制连同 libstd/libtest 打成 Fuchsia 包CML 清单 ffx package build、发布后经ffx test run在模拟器上执行并解析run_summary.json判定 PASSED/失败。debug子命令还能通过 zxdb 连接模拟器调试指定测试用例。这套基建与build-fuchsia.sh构成互补前者验证工具链能构建 Fuchsia后者验证工具链产出的程序能在 Fuchsia 上正确运行。总结故障处理Fuchsia 任务失败时用rustbot ping fuchsia联系 fuchsia 通知组CI 预检bors try jobsx86_64-fuchsia可在合并前验证 PR 是否破坏 Fuchsia 构建器本地复现src/ci/docker/run.sh x86_64-fuchsia一键构建注意 46G 磁盘与耗时相关脚本与镜像定义分别位于 build-fuchsia.sh 和 Dockerfile回归调查置KEEP_CHECKOUT1复用检出与构建产物通过 GN config 注入 rustflags、修改rustc_version_string触发全量重建、强制 ninja 失败以捕获实际 rustc 命令目标支持Fuchsia target 的正式支持说明见 rustc book 的 platform-support 章节。将 Fuchsia 集成测试跑通等于拿到了一个约 200 万行 Rust 代码的真实大型编译器消费者作为回归验证环境——这正是 rustc-dev-guide 将其纳入生态测试任务的核心价值所在。【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考