开始开发 ffx 子工具

FFX 子工具是 ffx CLI 可以运行的顶级命令。这些命令可以直接编译到 ffx 中,并且/或者构建为可在 build 输出目录或 SDK 中找到的单独命令,然后使用 FHO 工具界面调用这些命令。

放置位置

首先,在 fuchsia.git 树中的某个位置创建一个目录来存放子工具。目前,子工具位于以下位置:

  • ffx 插件树,仅内置插件和混合插件/子工具位于此处。通常不应将新子工具放置在此处。
  • ffx 工具树,仅外部运行的子工具位于此处。将其放置在此处有助于 ffx 的维护人员更轻松地帮助解决任何问题,或根据 ffx 与工具之间的接口发生的任何更改更新您的子工具。如果您将其放置在此处,并且 FFX 团队不是此工具的主要维护者,则必须在您放置该工具的目录中放置一个 OWNERS 文件,其中添加了您团队的组件和一些个人所有者,以便我们知道如何对您的工具进行问题分类。
  • 项目自己的树中的某个位置。如果 ffx 工具只是现有程序的封装容器,这种做法可能有意义,但如果您这样做,则必须设置 OWNERS 文件,以便 FFX 团队可以批准与 ffx 交互的部分的更新。为此,您可以将 file:/src/developer/ffx/OWNERS 添加到 OWNERS 文件中,并将其放在工具所在的子目录上。

除了不要将新工具放入插件之外,在确定具体位置时,可能还需要与工具团队讨论,以确定最佳位置。

哪些文件

确定工具的放置位置后,创建源文件。最佳实践是将工具的代码拆分为实现各项的库和仅调用该库的 main.rs

以下文件集是常见的起点:

BUILD.gn
src/lib.rs
src/main.rs
OWNERS

当然,您也可以根据需要将内容拆分到更多库中。请注意,这些示例均基于示例 echo 子工具,但为简洁起见,可能会移除或简化部分内容。如果此处的任何内容不起作用或看起来不清楚,请查看该目录中的文件。

BUILD.gn

以下是一个简单子工具的 BUILD.gn 文件示例。请注意,如果您习惯使用旧版插件接口,ffx_tool 操作不会强制您采用某种库结构,也不会执行任何非常复杂的操作。它是 rustc_binary 操作的封装容器,但添加了一些额外的目标,用于生成元数据、生成宿主工具和生成 SDK Atom。

# Copyright 2022 The Fuchsia Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.

import("//build/host.gni")
import("//build/rust/rustc_library.gni")
import("//src/developer/ffx/build/ffx_tool.gni")
import("//src/developer/ffx/lib/version/build/ffx_apply_version.gni")

rustc_library("lib") {
  # This is named as such to avoid a conflict with an existing ffx echo command.
  name = "ffx_tool_echo"
  edition = "2021"
  with_unit_tests = true

  deps = [
    "//src/developer/ffx/fidl:fuchsia.developer.ffx_rust",
    "//src/developer/ffx/lib/fho:lib",
    "//src/developer/ffx/lib/target/holders:lib",
    "//src/developer/ffx/lib/writer:lib",
    "//third_party/rust_crates:argh",
    "//third_party/rust_crates:async-trait",
  ]

  test_deps = [
    "//src/lib/fidl/rust/fidl",
    "//src/lib/fuchsia",
    "//src/lib/fuchsia-async",
    "//third_party/rust_crates:futures-lite",
  ]

  sources = [ "src/lib.rs" ]
}

ffx_tool("ffx_echo") {
  edition = "2021"
  output_name = "ffx-echo"
  deps = [
    ":lib",
    "//src/developer/ffx/lib/fho:lib",
    "//src/lib/fuchsia-async",
  ]
  sources = [ "src/main.rs" ]
}

group("echo") {
  public_deps = [
    ":ffx_echo",
    ":ffx_echo_host_tool",
  ]
}

group("bin") {
  public_deps = [ ":ffx_echo_versioned" ]
}

group("tests") {
  testonly = true
  deps = [ ":lib_test($host_toolchain)" ]
}

main.rs

主 Rust 文件通常非常简单,只需使用正确的类型调用 FHO,以用作 ffx 知道如何与之通信的入口点:

// Copyright 2022 The Fuchsia Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
use ffx_tool_echo::EchoTool;
use fho::FfxTool;

#[fuchsia_async::run_singlethreaded]
async fn main() {
    EchoTool::execute_tool().await
}

lib.rs

工具的主要代码将位于此处。在这里,您将为命令参数设置基于 argh 的结构体,并从用于存储工具运行所需上下文的结构体派生 FfxToolFfxMain 实现。

参数

#[derive(ArgsInfo, FromArgs, Debug, PartialEq)]
#[argh(subcommand, name = "echo", description = "run echo test against the daemon")]
pub struct EchoCommand {
    #[argh(positional)]
    /// text string to echo back and forth
    pub text: Option<String>,
}

此结构体用于定义子工具在其子命令名称后面需要的所有参数。

工具结构

#[derive(FfxTool)]
pub struct EchoTool {
    #[command]
    cmd: EchoCommand,
    #[with(daemon_protocol())]
    echo_proxy: ffx::EchoProxy,
}

此结构用于存储工具所需的上下文。这包括上述定义的实参结构、您可能需要的任何守护程序或设备代理,或者您可能自行定义的其他内容。

此结构体中必须有一个元素引用上述参数类型,并且该元素应具有 #[command] 属性,以便为 FfxTool 实现设置正确的关联类型。

此结构中的任何内容都必须实现 TryFromEnv,或者具有指向返回实现 TryFromEnvWith 的函数的 #[with()] 注解。fho 库或其他 ffx 库中还内置了这些功能的多个实现。

此外,工具上方的 #[check()] 注解使用 CheckEnv 的实现来验证命令应在不为结构体本身生成项的情况下运行。此处的 AvailabilityFlag 会检查实验性状态,如果未启用,则提前退出。编写新子命令时,应在其中添加此声明,以免用户在该子命令尚未准备好供更广泛使用时依赖于它。

FIDL 协议

FFX 子工具可以通过 Overnet 使用 FIDL 协议与目标设备通信。如需从子工具访问 FIDL 协议,请执行以下操作:

  1. 将 FIDL Rust 绑定作为依赖项添加到子工具的 BUILD.gn 文件中。以下示例为 fuchsia.device FIDL 库添加了绑定:

      deps = [
        "//sdk/fidl/fuchsia.device:fuchsia.device_rust",
      ]
    
  2. 将必要的绑定导入到子工具实现中。以下示例从 fuchsia.device 导入 NameProviderProxy

    use fidl_fuchsia_device::NameProviderProxy;
    
  3. 声明工具结构的成员字段。由于 FIDL 代理会实现 TryFromEnv trait,因此 FHO 框架会为您创建并初始化该字段。

    #[derive(FfxTool)]
    pub struct EchoTool {
      #[command]
      cmd: EchoCommand,
      name_proxy: NameProviderProxy,
    }
    

FfxMain 实现

#[async_trait(?Send)]
impl FfxMain for EchoTool {
    type Writer = MachineWriter<String>;
    async fn main(self, mut writer: Self::Writer) -> Result<()> {
        let text = self.cmd.text.as_deref().unwrap_or("FFX");
        let echo_out = self
            .echo_proxy
            .echo_string(text)
            .await
            .user_message("Error returned from echo service")?;
        writer.item(&echo_out)?;
        Ok(())
    }
}

您可以在此处实现实际的工具逻辑。您可以为 Writer 关联 trait 指定类型,系统会根据 ffx 的运行上下文为您初始化该类型(通过 TryFromEnv)。大多数新子工具应使用 MachineWriter<> 类型,指定的类型比上面的示例 String 更具体,但具体取决于工具。未来,所有新工具都可能需要实现机器接口。

此外,此函数的结果类型默认使用 fho Error 类型,可用于区分因用户互动而导致的错误和意外错误。如需了解详情,请参阅错误文档。

单元测试

如果您想对子工具进行单元测试,只需按照在主机上测试 Rust 代码的标准方法操作即可。当 with_unit_tests 参数设置为 true 时,ffx_plugin() GN 模板会为单元测试生成 <target_name>_lib_test 库目标。

如果您的 lib.rs 包含测试,则可以使用 fx test 调用这些测试:

fx test ffx_example_lib_test

如果 fx 测试找不到您的测试,请检查产品配置是否包含您的测试。您可以使用以下命令添加所有 ffx 测试:

fx set ... --with=//src/developer/ffx:tests

在测试中使用虚构的 FIDL 代理

测试子工具的常见模式是为 FIDL 协议创建虚假代理。这样,您就可以通过调用代理返回各种各样的结果,而无需实际处理集成测试的复杂性。

    fn setup_fake_echo_proxy() -> ffx::EchoProxy {
        let (proxy, mut stream) = fidl::endpoints::create_proxy_and_stream::<ffx::EchoMarker>();
        fuchsia_async::Task::local(async move {
            while let Ok(Some(req)) = stream.try_next().await {
                match req {
                    ffx::EchoRequest::EchoString { value, responder } => {
                        responder.send(value.as_ref()).unwrap();
                    }
                }
            }
        })
        .detach();
        proxy
    }

然后,在单元测试中使用此虚构代理

    #[fuchsia::test]
    async fn test_regular_run() {
        const ECHO: &'static str = "foo";
        let cmd = EchoCommand { text: Some(ECHO.to_owned()) };
        let echo_proxy = setup_fake_echo_proxy();
        let test_stdout = TestBuffer::default();
        let writer = MachineWriter::new_buffers(None, test_stdout.clone(), Vec::new());
        let tool = EchoTool { cmd, echo_proxy };
        tool.main(writer).await.unwrap();
        assert_eq!(format!("{ECHO}\n"), test_stdout.into_string());
    }

OWNERS

如果此子工具位于 ffx 树中,您需要添加 OWNERS 文件,以告知我们谁负责此代码,以及如何在分类中转送与此代码相关的问题。它应如下所示:

file:/path/to/authoritative/OWNERS

最好将其添加为引用(使用 file: 或可能的 include),而不是直接添加人员列表,以免其因不碍事而过时。

添加到 build

如需将该工具作为托管工具添加到 GN build 图中,您需要在 ffx 工具 gn 文件的主列表中引用该工具,并将其添加到 toolstest 组的 public_deps

之后,如果您 fx build ffx,应该可以在 ffx commands 的输出中 Workspace Commands 列表中看到您的工具,并且应该能够运行该工具。

实验性子工具和子命令

建议子工具最初不要在其 BUILD.gn 中包含 sdk_category。这些未指定类别的子工具被视为“内部”工具,不会纳入 SDK 中。如果用户想使用该二进制文件,则必须直接向他们提供该二进制文件。

不过,子命令的处理方式有所不同。

子命令需要向工具添加 AvailabilityFlag 属性(如需查看示例,请参阅 ffx target update 历史记录中的提交)。如果用户想使用子命令,则需要设置关联的配置选项,才能调用该子命令。

不过,这种方法存在问题,例如没有对子命令的 FIDL 依赖项进行任何验证。因此,自 2023 年 12 月起,我们将更改处理子命令的机制。

与子工具类似,子命令将能够声明其 SDK 类别,以确定子命令是否在 SDK 中可用。子工具将仅使用子工具类别级别或更高级别的子命令进行构建。FIDL 依赖项检查将正确验证子命令的要求。

添加到 SDK

工具稳定下来并准备好将其添加到 SDK 中后,您需要将二进制文件添加到 SDK build 中。请注意,在执行此操作之前,必须确保该工具相对稳定且经过充分测试(尽可能不要已将其包含在 SDK 中),并且您需要确保已考虑兼容性问题。

兼容性

在将子工具添加到 SDK 和 IDK 之前,您需要注意以下三个方面:

  1. FIDL 库 - 向 SDK 添加子工具时,您必须将依赖的所有 FIDL 库添加到 SDK。(如需了解详情,请参阅将 API 提升到 host_tool。)

  2. 命令行参数 - 为了测试是否因命令行选项更改而发生破坏性更改,系统会使用 ArgsInfo 派生宏生成命令行的 JSON 表示法。

    此参数在基准文件测试中用于检测差异。黄金文件。最终,此测试将得到增强,以检测破坏向后兼容性的更改并发出警告。

  3. 适合机器的输出 - 工具和子命令应尽可能提供机器输出,尤其是在测试或构建脚本中使用的工具。MachineWriter 对象用于简化以 JSON 格式编码输出,并提供用于检测输出结构更改的架构。

    机器输出必须在当前兼容性时间范围内保持稳定。最终,机器输出格式将有一个标准检查。使用机器写手输出的优势在于,您可以自由地在自由文本中获得不稳定的输出。

更新子工具

如需将子工具添加到 SDK,请将其 BUILD.gn 中的 sdk_category 设置为相应类别(例如 partner)。如果子工具包含不再处于实验阶段的子命令,请移除其 AvailabilityFlag 属性,以便它们不再需要特殊的配置选项即可调用。

纳入 SDK

您还需要将子工具添加到 SDK GN 文件host_tools 分子中,例如:

sdk_molecule("host_tools") {
  visibility = [ ":*" ]

  _host_tools = [
    ...
    "//path/to/your/tool:sdk", # <-- insert this
    ...
  ]
]

用户体验和 SDK 审核

子工具必须遵循 CLI 准则