Flutter 使用ledCLI 为 PR 运行 DeviceLab 与 Post-submit 测试的完整指南【免费下载链接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond项目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter本篇技术指南围绕 Flutter 仓库中的 Agent 技能文档 .agents/skills/run-devicelab-with-led/SKILL.md 展开讲解如何借助 LUCI 的led命令行工具为某个 Pull Request 重新触发 post-submit 或 DeviceLab 测试例如 PR 合入后看板变红、或需要在合入前对 flaky 测试多跑几轮验证。读完本文你将掌握led get-builder、led edit、led edit-recipe-bundle、led launch组成的完整命令管道的用法、每个参数的含义以及该流程与仓库内 .ci.yaml 构建器定义、dev/bots/README.md 和 dev/devicelab/README.md 之间的对应关系。什么场景需要手动用led跑 DeviceLab 测试官方配套文档 docs/infra/Running-Devicelab-Tests-For-PR.md 给出了两类典型动机PR 已合入但看板变红pre-submit 阶段全部通过但 post-submit提交后构建失败需要手动重新触发对应测试Deflake验证测试稳定性怀疑某个测试是 flaky 的需要把它重复跑几轮确认而不是直接基于一次失败下结论。技能文档 SKILL.md 将其描述为当你被要求 run / launch / try / deflake a post-submit or devicelab test against a PR usingled 时使用本流程。DeviceLab 本身是 Flutter 的物理设备实验室dev/devicelab/README.md 说明任务会按设备类型linux_android、mac_ios、windows_android等分配给空闲设备失败的任务会自动重跑只有当某次重跑成功后该任务才报告成功并标记 flake——这正是手动多跑几次来 deflake这一需求的底层机制。前置条件Prerequisites技能文档列出了三条硬性前置条件在开始执行命令管道之前应逐条验证#前置条件验证方式说明1led工具可用执行led auth-infoled来自 Google 的depot_tools项目必须已安装并在PATH中2SSO 认证有效执行gcertstatus或glogin status凭据过期时需用户执行glogin或gcert重新认证recipes 仓库的 git 操作依赖 SSO 认证3recipes仓库 checkout仅在用到led edit-recipe-bundle时必需从 Flutterrecipes仓库根目录执行命令用于测试本地 recipe 改动或 recipe-only 的 PR执行git clone https://flutter.googlesource.com/recipes获取此外技能文档的头部注释Host assumptions明确要求执行环境还具备已安装且在PATH中的工具led来自 depot_tools、git、gh已完成认证的led、gh、gcert/glogin。同时需注意 dev/bots/README.md 中的通用基建前置使用 Flutter 构建基础设施需要depot_toolsled即随其分发并且 dev/bots/README.md#L54-L79 中Editing a recipe一节的典型 recipe 编辑循环第 4 步与本技能文档给出的是同一条led管道两者互为印证。若led命令失败该文档建议先确认depot_toolscheckout 已是最新。工作流第一步按 PR 类型收集输入执行管道前需收集两个必需参数PR_NUMBER目标 Pull Request 的编号例如123456。它将被拼进 LUCI 的 git ref即refs/pull/PR_NUMBER/head指向 PR 分支的最新提交PRESUBMIT_TEST要运行的 LUCIstaging builder 的精确名称例如Windows_mokey hot_mode_dev_cycle_win__benchmark或Mac_ios microbenchmarks_ios。注意 builder 名称可能包含空格命令中需要整体用引号包住。builder 名称不是凭空指定的——它必须对应 .ci.yaml 中已定义的构建器。以文档示例中的Windows_mokey hot_mode_dev_cycle_win__benchmark为例可在 .ci.yaml#L7615-L7622 中确认其定义# windows mokey benchmark - name: Windows_mokey hot_mode_dev_cycle_win__benchmark recipe: devicelab/devicelab_drone presubmit: false timeout: 60 properties: tags: [devicelab, android, windows, mokey] task_name: hot_mode_dev_cycle_win__benchmark从这段配置可以看出该构建器使用devicelab/devicelab_dronerecipe 在 Windows mokey 机器带 Android 设备的物理机上执行presubmit: false表明它是提交后post-submit而非 PR 检查阶段运行的测试超时 60 分钟实际执行的任务由properties.task_name指定。这也解释了为什么该测试属于post-submit类别、需要借助本流程手动针对 PR 触发。工作流第二步执行led命令管道关于工作目录如果本次执行包含led edit-recipe-bundle且目的是测试本地 recipe 修改必须先cd到本地recipes仓库的根目录再执行管道——led edit-recipe-bundle会把当前工作目录$CWD打包为 recipe bundle 并随构建一起下发。如果只是想针对 PR 跑测试而没有本地 recipe 改动led edit-recipe-bundle这一环可以从 recipes checkout 目录运行也可以从管道中省略。命令管道技能文档给出的标准管道如下将PRESUBMIT_TEST与PR_NUMBER替换为实际值led get-builder luci.flutter.staging:PRESUBMIT_TEST \ | led edit -pa git_refrefs/pull/PR_NUMBER/head \ | led edit -pa git_urlhttps://github.com/flutter/flutter \ | led edit-recipe-bundle \ | led launch各阶段作用解析led get-builder luci.flutter.staging:PRESUBMIT_TEST从 LUCI 的luci.flutter.staging项目bucket中拉取指定 builder 的完整构建定义含 recipe、properties、dependencies 等作为后续编辑的基础。staging bucket 的意义在于它不会污染正式主干流水线专门用于此类针对 PR 的手动触发led edit -pa git_refrefs/pull/PR_NUMBER/head-pa即set property设置构建属性。将待测代码来源覆盖为 PR 分支的最新提交。构建机上会以此 ref 检出代码led edit -pa git_urlhttps://github.com/flutter/flutter将代码来源 URL 覆盖为 framework 仓库。对 framework 的 PR 用上述地址对 engine 仓库的 PR 则应改为 engine 对应的仓库地址dev/bots/README.md#L73-L74 中同样以git_ref/git_url指向intended changes to build的表述说明了这两个属性的含义led edit-recipe-bundle将本地recipescheckout当前目录打包为 recipe bundle使本次构建使用本地修改后的 recipe 而非 LUCI 上已发布的版本。仅在测试本地 recipe 改动时需要led launch提交构建到 LUCI 调度执行。工作流第三步回报已启动任务的信息led launch执行后会输出关于所启动构建的详细信息包括Swarming / LUCI 任务链接。正确的收尾动作是把该 URL 提供给用户以便其跟踪执行进度、查看构建日志。对 DeviceLab 类构建而言日志中还包含任务在物理设备上的执行过程测试最终状态成功 / 失败 / flake 标记则体现在 dev/devicelab/README.md 所描述的自动重跑与结果上报机制中。完整示例为 framework PR 运行Windows_mokey hot_mode_dev_cycle_win__benchmark技能文档给出了一条用户提示 → 具体动作的对照示例用户提示Run the devicelab testWindows_mokey hot_mode_dev_cycle_win__benchmarkfor framework PR 12345 with led.动作运行以下命令若为测试本地 recipe 改动先切换到本地recipes/目录led get-builder luci.flutter.staging:Windows_mokey hot_mode_dev_cycle_win__benchmark \ | led edit -pa git_refrefs/pull/12345/head \ | led edit -pa git_urlhttps://github.com/flutter/flutter \ | led edit-recipe-bundle \ | led launch对照仓库证据可以完整解释这条命令luci.flutter.staging定位 staging 项目中的 builderbuilder 名称与 .ci.yaml#L7615-L7622 中的定义逐字一致git_ref指向 PR 12345 的 head 提交git_url表明被测代码来自 framework 仓库edit-recipe-bundle使本次运行带上本地 recipe 改动若无需验证 recipe 可去掉该行launch将构建下发到devicelab/devicelab_dronerecipe 对应的 Windows Android 物理设备执行。适用前提与限制小结本流程依赖 Google 内部基建LUCI / Swarming / depot_tools 中的led、SSO 认证面向 Flutter 基础设施贡献者普通用户无需也无法执行dev/bots/README.md 亦说明 Flutter 构建看板的重新触发需要特殊权限需提team-infraissue 申请PRESUBMIT_TEST必须是 LUCI staging builder 的精确全名可在 .ci.yamlframework与 engine 侧配置中查找使用led edit-recipe-bundle时工作目录必须是recipes仓库根目录且 recipes 改动应遵循 dev/bots/README.md#L54-L79 的 recipe 编辑规范如recipes.py test train更新期望输出、recipe 需 100% 测试覆盖led执行失败时优先检查depot_tools是否已更新、SSO 凭据gcertstatus/glogin status是否过期。【免费下载链接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond项目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Flutter 使用ledCLI 为 PR 运行 DeviceLab 与 Post-submit 测试的完整指南【免费下载链接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond项目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter本篇技术指南围绕 Flutter 仓库中的 Agent 技能文档 .agents/skills/run-devicelab-with-led/SKILL.md 展开讲解如何借助 LUCI 的led命令行工具为某个 Pull Request 重新触发 post-submit 或 DeviceLab 测试例如 PR 合入后看板变红、或需要在合入前对 flaky 测试多跑几轮验证。读完本文你将掌握led get-builder、led edit、led edit-recipe-bundle、led launch组成的完整命令管道的用法、每个参数的含义以及该流程与仓库内 .ci.yaml 构建器定义、dev/bots/README.md 和 dev/devicelab/README.md 之间的对应关系。什么场景需要手动用led跑 DeviceLab 测试官方配套文档 docs/infra/Running-Devicelab-Tests-For-PR.md 给出了两类典型动机PR 已合入但看板变红pre-submit 阶段全部通过但 post-submit提交后构建失败需要手动重新触发对应测试Deflake验证测试稳定性怀疑某个测试是 flaky 的需要把它重复跑几轮确认而不是直接基于一次失败下结论。技能文档 SKILL.md 将其描述为当你被要求 run / launch / try / deflake a post-submit or devicelab test against a PR usingled 时使用本流程。DeviceLab 本身是 Flutter 的物理设备实验室dev/devicelab/README.md 说明任务会按设备类型linux_android、mac_ios、windows_android等分配给空闲设备失败的任务会自动重跑只有当某次重跑成功后该任务才报告成功并标记 flake——这正是手动多跑几次来 deflake这一需求的底层机制。前置条件Prerequisites技能文档列出了三条硬性前置条件在开始执行命令管道之前应逐条验证#前置条件验证方式说明1led工具可用执行led auth-infoled来自 Google 的depot_tools项目必须已安装并在PATH中2SSO 认证有效执行gcertstatus或glogin status凭据过期时需用户执行glogin或gcert重新认证recipes 仓库的 git 操作依赖 SSO 认证3recipes仓库 checkout仅在用到led edit-recipe-bundle时必需从 Flutterrecipes仓库根目录执行命令用于测试本地 recipe 改动或 recipe-only 的 PR执行git clone https://flutter.googlesource.com/recipes获取此外技能文档的头部注释Host assumptions明确要求执行环境还具备已安装且在PATH中的工具led来自 depot_tools、git、gh已完成认证的led、gh、gcert/glogin。同时需注意 dev/bots/README.md 中的通用基建前置使用 Flutter 构建基础设施需要depot_toolsled即随其分发并且 dev/bots/README.md#L54-L79 中Editing a recipe一节的典型 recipe 编辑循环第 4 步与本技能文档给出的是同一条led管道两者互为印证。若led命令失败该文档建议先确认depot_toolscheckout 已是最新。工作流第一步按 PR 类型收集输入执行管道前需收集两个必需参数PR_NUMBER目标 Pull Request 的编号例如123456。它将被拼进 LUCI 的 git ref即refs/pull/PR_NUMBER/head指向 PR 分支的最新提交PRESUBMIT_TEST要运行的 LUCIstaging builder 的精确名称例如Windows_mokey hot_mode_dev_cycle_win__benchmark或Mac_ios microbenchmarks_ios。注意 builder 名称可能包含空格命令中需要整体用引号包住。builder 名称不是凭空指定的——它必须对应 .ci.yaml 中已定义的构建器。以文档示例中的Windows_mokey hot_mode_dev_cycle_win__benchmark为例可在 .ci.yaml#L7615-L7622 中确认其定义# windows mokey benchmark - name: Windows_mokey hot_mode_dev_cycle_win__benchmark recipe: devicelab/devicelab_drone presubmit: false timeout: 60 properties: tags: [devicelab, android, windows, mokey] task_name: hot_mode_dev_cycle_win__benchmark从这段配置可以看出该构建器使用devicelab/devicelab_dronerecipe 在 Windows mokey 机器带 Android 设备的物理机上执行presubmit: false表明它是提交后post-submit而非 PR 检查阶段运行的测试超时 60 分钟实际执行的任务由properties.task_name指定。这也解释了为什么该测试属于post-submit类别、需要借助本流程手动针对 PR 触发。工作流第二步执行led命令管道关于工作目录如果本次执行包含led edit-recipe-bundle且目的是测试本地 recipe 修改必须先cd到本地recipes仓库的根目录再执行管道——led edit-recipe-bundle会把当前工作目录$CWD打包为 recipe bundle 并随构建一起下发。如果只是想针对 PR 跑测试而没有本地 recipe 改动led edit-recipe-bundle这一环可以从 recipes checkout 目录运行也可以从管道中省略。命令管道技能文档给出的标准管道如下将PRESUBMIT_TEST与PR_NUMBER替换为实际值led get-builder luci.flutter.staging:PRESUBMIT_TEST \ | led edit -pa git_refrefs/pull/PR_NUMBER/head \ | led edit -pa git_urlhttps://github.com/flutter/flutter \ | led edit-recipe-bundle \ | led launch各阶段作用解析led get-builder luci.flutter.staging:PRESUBMIT_TEST从 LUCI 的luci.flutter.staging项目bucket中拉取指定 builder 的完整构建定义含 recipe、properties、dependencies 等作为后续编辑的基础。staging bucket 的意义在于它不会污染正式主干流水线专门用于此类针对 PR 的手动触发led edit -pa git_refrefs/pull/PR_NUMBER/head-pa即set property设置构建属性。将待测代码来源覆盖为 PR 分支的最新提交。构建机上会以此 ref 检出代码led edit -pa git_urlhttps://github.com/flutter/flutter将代码来源 URL 覆盖为 framework 仓库。对 framework 的 PR 用上述地址对 engine 仓库的 PR 则应改为 engine 对应的仓库地址dev/bots/README.md#L73-L74 中同样以git_ref/git_url指向intended changes to build的表述说明了这两个属性的含义led edit-recipe-bundle将本地recipescheckout当前目录打包为 recipe bundle使本次构建使用本地修改后的 recipe 而非 LUCI 上已发布的版本。仅在测试本地 recipe 改动时需要led launch提交构建到 LUCI 调度执行。工作流第三步回报已启动任务的信息led launch执行后会输出关于所启动构建的详细信息包括Swarming / LUCI 任务链接。正确的收尾动作是把该 URL 提供给用户以便其跟踪执行进度、查看构建日志。对 DeviceLab 类构建而言日志中还包含任务在物理设备上的执行过程测试最终状态成功 / 失败 / flake 标记则体现在 dev/devicelab/README.md 所描述的自动重跑与结果上报机制中。完整示例为 framework PR 运行Windows_mokey hot_mode_dev_cycle_win__benchmark技能文档给出了一条用户提示 → 具体动作的对照示例用户提示Run the devicelab testWindows_mokey hot_mode_dev_cycle_win__benchmarkfor framework PR 12345 with led.动作运行以下命令若为测试本地 recipe 改动先切换到本地recipes/目录led get-builder luci.flutter.staging:Windows_mokey hot_mode_dev_cycle_win__benchmark \ | led edit -pa git_refrefs/pull/12345/head \ | led edit -pa git_urlhttps://github.com/flutter/flutter \ | led edit-recipe-bundle \ | led launch对照仓库证据可以完整解释这条命令luci.flutter.staging定位 staging 项目中的 builderbuilder 名称与 .ci.yaml#L7615-L7622 中的定义逐字一致git_ref指向 PR 12345 的 head 提交git_url表明被测代码来自 framework 仓库edit-recipe-bundle使本次运行带上本地 recipe 改动若无需验证 recipe 可去掉该行launch将构建下发到devicelab/devicelab_dronerecipe 对应的 Windows Android 物理设备执行。适用前提与限制小结本流程依赖 Google 内部基建LUCI / Swarming / depot_tools 中的led、SSO 认证面向 Flutter 基础设施贡献者普通用户无需也无法执行dev/bots/README.md 亦说明 Flutter 构建看板的重新触发需要特殊权限需提team-infraissue 申请PRESUBMIT_TEST必须是 LUCI staging builder 的精确全名可在 .ci.yamlframework与 engine 侧配置中查找使用led edit-recipe-bundle时工作目录必须是recipes仓库根目录且 recipes 改动应遵循 dev/bots/README.md#L54-L79 的 recipe 编辑规范如recipes.py test train更新期望输出、recipe 需 100% 测试覆盖led执行失败时优先检查depot_tools是否已更新、SSO 凭据gcertstatus/glogin status是否过期。【免费下载链接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond项目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
