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本篇技術(shù)指南圍繞 Flutter 倉庫中的 Agent 技能文檔 .agents/skills/run-devicelab-with-led/SKILL.md 展開講解如何借助 LUCI 的led命令行工具為某個 Pull Request 重新觸發(fā) post-submit 或 DeviceLab 測試例如 PR 合入后看板變紅、或需要在合入前對 flaky 測試多跑幾輪驗證。讀完本文你將掌握led get-builder、led edit、led edit-recipe-bundle、led launch組成的完整命令管道的用法、每個參數(shù)的含義以及該流程與倉庫內(nèi) .ci.yaml 構(gòu)建器定義、dev/bots/README.md 和 dev/devicelab/README.md 之間的對應關系。什么場景需要手動用led跑 DeviceLab 測試官方配套文檔 docs/infra/Running-Devicelab-Tests-For-PR.md 給出了兩類典型動機PR 已合入但看板變紅pre-submit 階段全部通過但 post-submit提交后構(gòu)建失敗需要手動重新觸發(fā)對應測試Deflake驗證測試穩(wěn)定性懷疑某個測試是 flaky 的需要把它重復跑幾輪確認而不是直接基于一次失敗下結(jié)論。技能文檔 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技能文檔列出了三條硬性前置條件在開始執(zhí)行命令管道之前應逐條驗證#前置條件驗證方式說明1led工具可用執(zhí)行l(wèi)ed auth-infoled來自 Google 的depot_tools項目必須已安裝并在PATH中2SSO 認證有效執(zhí)行g(shù)certstatus或glogin status憑據(jù)過期時需用戶執(zhí)行g(shù)login或gcert重新認證recipes 倉庫的 git 操作依賴 SSO 認證3recipes倉庫 checkout僅在用到led edit-recipe-bundle時必需從 Flutterrecipes倉庫根目錄執(zhí)行命令用于測試本地 recipe 改動或 recipe-only 的 PR執(zhí)行g(shù)it clone https://flutter.googlesource.com/recipes獲取此外技能文檔的頭部注釋Host assumptions明確要求執(zhí)行環(huán)境還具備已安裝且在PATH中的工具led來自 depot_tools、git、gh已完成認證的led、gh、gcert/glogin。同時需注意 dev/bots/README.md 中的通用基建前置使用 Flutter 構(gòu)建基礎設施需要depot_toolsled即隨其分發(fā)并且 dev/bots/README.md#L54-L79 中Editing a recipe一節(jié)的典型 recipe 編輯循環(huán)第 4 步與本技能文檔給出的是同一條led管道兩者互為印證。若led命令失敗該文檔建議先確認depot_toolscheckout 已是最新。工作流第一步按 PR 類型收集輸入執(zhí)行管道前需收集兩個必需參數(shù)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 中已定義的構(gòu)建器。以文檔示例中的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從這段配置可以看出該構(gòu)建器使用devicelab/devicelab_dronerecipe 在 Windows mokey 機器帶 Android 設備的物理機上執(zhí)行presubmit: false表明它是提交后post-submit而非 PR 檢查階段運行的測試超時 60 分鐘實際執(zhí)行的任務由properties.task_name指定。這也解釋了為什么該測試屬于post-submit類別、需要借助本流程手動針對 PR 觸發(fā)。工作流第二步執(zhí)行l(wèi)ed命令管道關于工作目錄如果本次執(zhí)行包含led edit-recipe-bundle且目的是測試本地 recipe 修改必須先cd到本地recipes倉庫的根目錄再執(zhí)行管道——led edit-recipe-bundle會把當前工作目錄$CWD打包為 recipe bundle 并隨構(gòu)建一起下發(fā)。如果只是想針對 PR 跑測試而沒有本地 recipe 改動led edit-recipe-bundle這一環(huán)可以從 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 的完整構(gòu)建定義含 recipe、properties、dependencies 等作為后續(xù)編輯的基礎。staging bucket 的意義在于它不會污染正式主干流水線專門用于此類針對 PR 的手動觸發(fā)led edit -pa git_refrefs/pull/PR_NUMBER/head-pa即set property設置構(gòu)建屬性。將待測代碼來源覆蓋為 PR 分支的最新提交。構(gòu)建機上會以此 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使本次構(gòu)建使用本地修改后的 recipe 而非 LUCI 上已發(fā)布的版本。僅在測試本地 recipe 改動時需要led launch提交構(gòu)建到 LUCI 調(diào)度執(zhí)行。工作流第三步回報已啟動任務的信息led launch執(zhí)行后會輸出關于所啟動構(gòu)建的詳細信息包括Swarming / LUCI 任務鏈接。正確的收尾動作是把該 URL 提供給用戶以便其跟蹤執(zhí)行進度、查看構(gòu)建日志。對 DeviceLab 類構(gòu)建而言日志中還包含任務在物理設備上的執(zhí)行過程測試最終狀態(tài)成功 / 失敗 / flake 標記則體現(xiàn)在 dev/devicelab/README.md 所描述的自動重跑與結(jié)果上報機制中。完整示例為 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對照倉庫證據(jù)可以完整解釋這條命令luci.flutter.staging定位 staging 項目中的 builderbuilder 名稱與 .ci.yaml#L7615-L7622 中的定義逐字一致git_ref指向 PR 12345 的 head 提交git_url表明被測代碼來自 framework 倉庫edit-recipe-bundle使本次運行帶上本地 recipe 改動若無需驗證 recipe 可去掉該行l(wèi)aunch將構(gòu)建下發(fā)到devicelab/devicelab_dronerecipe 對應的 Windows Android 物理設備執(zhí)行。適用前提與限制小結(jié)本流程依賴 Google 內(nèi)部基建LUCI / Swarming / depot_tools 中的led、SSO 認證面向 Flutter 基礎設施貢獻者普通用戶無需也無法執(zhí)行dev/bots/README.md 亦說明 Flutter 構(gòu)建看板的重新觸發(fā)需要特殊權(quán)限需提t(yī)eam-infraissue 申請PRESUBMIT_TEST必須是 LUCI staging builder 的精確全名可在 .ci.yamlframework與 engine 側(cè)配置中查找使用led edit-recipe-bundle時工作目錄必須是recipes倉庫根目錄且 recipes 改動應遵循 dev/bots/README.md#L54-L79 的 recipe 編輯規(guī)范如recipes.py test train更新期望輸出、recipe 需 100% 測試覆蓋led執(zhí)行失敗時優(yōu)先檢查depot_tools是否已更新、SSO 憑據(jù)gcertstatus/glogin status是否過期。【免費下載鏈接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond項目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考