RFC-0095 - 從樹狀結構外建構及組合工作站

RFC-0095：建構及組合工作站的樹狀結構外
狀態已接受
領域
  • 一般
說明

建立工作流程，讓使用者在 fuchsia.git 之外建構及組合 Workstations 產品。
毛皮變化
作者
審查人員
提交日期 (年-月-日)2021-03-24
審查日期 (年-月-日)2021-05-19

編輯此 RFC

編輯 RFC 中繼資料

摘要

注意：這個 RFC 已由 RFC-0220 取代，現已淘汰 工作站產品此 RFC 會留待日後保留，但我們不會這麼做 可加快執行速度

Workstations 產品，定義為 worker_session、ermine 和終端機 和簡易瀏覽器，目前建構及組裝於 Fuchsia 原始碼樹狀結構中。 Fuchsia 平台和工作站之間沒有明顯的差異 產品。為此，平台和產品都必須 組合最終產品我們認為，這種耦合設計是故障 讓 Workstations 元件能夠獨立於平台外建構 最終產品會組裝在 Fuchsia 原始碼樹外。這個 無法解決從 樹皮來源樹，但著重於樹狀結構外的附屬問題 以及產品設定和組合這項工作將會奠定良好基礎 最後將 Workstations 產品完全樹狀結構外結構 提及範圍

值得一提的是，感應式刷卡機將視為 但終端機產品會由其他元件使用 Workstations 產品外的產品因此，編碼器-解碼器架構 該元件會保留在 fuchsia.git 中，並由 平臺本身，直到做出進一步決策為止 這個元件的未來發展

提振精神

目前沒有方法在 Fuchsia 上建構及組裝產品 同時建置整個 Fuchsia 平台。我們可以建立個別的 也就是 fuchsia.git 之外的元件，但這些成果需要 返回 Fuchsia Global 整合並組合成最終產品。三 我們希望能提供穩定版本的平台 。

想建構樹狀結構外產品時，仍有許多未知因素 所以我們想先介紹 Workstations 產品工作站 產品不是正式環境等級 支援的使用者產品 供開發人員和早期採用平台的環境參考 所以對於偵測速度變慢的容忍度較高 階段。Workstations 產品 適用於 愛好者可以探索 Fuchsia；讓您不必建構 ，讓開發人員更容易使用 Fuchsia。

設計

搬家工作站樹狀結構外以獨立圖像組件為基礎 工具 RFC-0072， 本提案假設其有這項工具。

存放區

Workstations 存放區的原始碼會 git-on-borg。在 git-on-borg 上託管程式碼後 就能使用現有的 Fuchsia 基礎架構和工具 專注於建構及組合產品的工作。

在本文件 worker.git 的其餘部分，會參照存放區 負責託管 Workstations 產品的程式碼

基礎設施

這項專案的重點在於建構及組合 Workstations 產品 因此我們不會將元件開發工作移出樹狀結構外 直到我們開始練習為止由於元件 開發中的應用程式仍會保留樹狀結構內中，我們可以使用現有的測試並 確認 Workstations 產品不會迴歸 將新版平台、sdk、體驗.git 和其他應用程式的新版本 應以指令碼手動處理依附元件，讓團隊能專心處理 解決手上的問題當我們開始轉換 因此，我們必須重新審視持續整合的方式。

平台的每日版本必須自動化，但我們可以使用 現有的 Fuchsia 基礎架構。需要建立每日建構工具 建構組合 Workstations 產品所需的套件，並上傳 複製到某些儲存空間存放區這個工作流程的技術設計 以便解決這個問題我們會先諮詢基礎設施與資安團隊，再進行諮詢 我們會開始處理

建構 Workstations 產品 (而非核心) 時，可確保我們 所有必要的產品組裝產物 我們將透過樹狀結構導入的構件 以便掌握使用平台擲回的構件這麼做也能讓我們 請使用現有的工作站建構工具，將額外 所需的基礎架構

依附元件管理

Workstations 存放區將使用 Git 子模組和 Bazel 的組合 以及運用工作區管理依附元件Git 子模組將用來提取外部 而 Bazel 將用於下載預先建構和工具鍊 所需的程式碼

Bazel 的工具鍊將 可與工作區規則搭配使用，以下載合適的預先建構項目 而各個建構規則所需的資源目前，這項限制有一項限制： 許多預先建材都儲存在 CIPD 中 而且需要使用 cipd 指令列工具最初的原型需要 工具就在開發人員路徑中我們積極尋找改變性元素 而且不認為這將不是長期規定

目錄結構

Workstations 存放區的目錄結構與 fuchsia.git 目錄結構，讓 Fuchsia 開發人員得以保持一致。 根目錄中包含專案所需的各種中繼資料檔案 以及下列頂層目錄

  • //src - 用於建構 Workstations 產品的原始碼。
  • //tools - 支援該版本的指令碼和工具。
  • //src/experiences - 現有的 experiences.git 存放區。
  • //預建 - 任何所需的預建項目。
  • //third_party - src 目錄使用的第三方程式碼。

建構系統

系統會使用 Bazel 建構工作站產品 建構系統相較於使用 gn/ninja。這項決定意味著我們無法擁抱專業知識。 確認 Fuchsia 團隊獲取或重複使用現有的建構規則。不過 目前的 gn SDK 不包含任何用來建構或測試 Flutter 的邏輯 這是 Workstations 產品的主要應用程式團隊 無論選擇哪種建構系統，都需要編寫這些規則。範例 樹狀結構內存在的 Bazel SDK 有一些基本邏輯，可供建構 我們可以做為建構基礎的 Dart 和 Flutter 應用程式

Workstations 團隊選擇使用 Bazel 來處理 gn/ninja，但有以下幾個主要原因： 這些習慣讓這個建構系統更具吸引力

  • Bazel 仍是常用建構系統 的採用率比 gn/ninja 更多，因此熟悉 開放原始碼社群

  • Bazel 的現有規則生態系統豐富，有助於排除規則本身 鼓吹重複使用

  • 依附元件管理：Bazel 可以管理外部依附元件。

  • Fuchsia SDK Bazel SDK 實際工作環境化：使用 Bazel 處理 Workstations 產品 讓我們有機會將變更推送至 Fuchsia Bazel SDK 其他專案所用的資源

  • 單一建構/分析階段：面對 Fuchsia 的開發人員經常提出的申訴 他們不知道為什麼建構中未包含套件或工具。這個 導致使用者必須將目標放在 gn 引數中。Bazel 移除 需要使用者明確指定 建構、執行或測試

  • 她的模型建立：Bazel 預設有密封的建構作業，但 gn 不會。

在這個階段，我們需要撰寫建構規則來打造體驗 將檔案複製到 worker.git buildroot我們會利用 Bazel 的 new_local_repository 功能。如此一來，我們就能 請將 Bazel 專屬的建構規則保留在 worker.git 中 從體驗存放區對應的來源請特別注意 這項設定很容易建構中斷，因為 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")

語言支援

Workstations 元件目前以 Dart 和 Rust 編寫，後者 是樹狀結構外開發目前僅支援目前支援的語言。 worker_session 和終端機元件是以 Rust 和 Ermine 編寫 和簡單瀏覽器都是以 Dart 編寫而成我們會先將注意力放在 同時繼續建構 Rust 元件 並以平台的形式提供

目前建構 worker_session 的障礙 樹狀結構外。第一個選項是 worker_session 使用 因此即使有 API 以及支援語言第二個攔截器是缺少樹狀結構外受到支援的支援。 Worker_session 目前拆分為較小的平台層級 不需要依賴私人介面 我們會探討 Rust 的樹狀結構外支援。我們將做出決定 將 worker_session 的例項化。如果 Worker_session 會從私人介面完全遷移，但 Rust 之後，我們很快就會在 C++ 中重新編寫工作階段 如果 Rust 支援的時間較早或不久， 以 Rust 編寫而成

消毒液

fuchsia.git 樹狀結構支援多種本機開發與清理工具 基礎架構建構工具的任務針對 worker.git 支援這些系統 由於我們不會將原始碼移出，因此存放區並非即時目標 直到我們確認建構和組件系統可以使用 存放區中對應的但我們應該阻止將程式碼移出 fuchsia.git 直到我們支援掃毒程式，因為它引進了 設定。

當我們能正常使用本機版本時，我們將新增對傳遞版本的支援 時間標記，以便在本機啟用多種消毒液。這樣我們就能 以啟用防毒液所對應之來源對應。當我們開始移動程式碼時 就會根據目前的服務體驗建立建構工具 新增至 fuchsia.git.

目前可透過程式碼搜尋搜尋 Fuchsia 程式碼。 Worker.git 存放區會做為獨立專案，新增至這項專案 並開放使用者在線上搜尋及瀏覽該作品。

程式碼涵蓋率

我們不打算在開頭 且近期沒有任何計畫。主要原因 大部分的工作站程式碼都是以 Dart 編寫， 而且具備足夠的程式碼涵蓋率支援，讓我們能 所需的時間。

我們會失去與目前編寫 c++ 程式碼相同的體驗， 顯示了漸進式程式碼涵蓋率，但在此模型中 worker.git 過大，而無法執行。但確實能 為 Fuchsia 建立團隊 創造一個好機會，讓這些工具能 樹狀結構外開發人員輕鬆使用。

第三方支援

您在 worker.git 中編寫的所有原始碼都必須共用相同的 第三方程式庫這項功能支援許多工具 都能順暢運作 而且不需要從頭開始 這代表我們必須執行大量的工作，並支持 執行整個專案

授權法規遵循必須符合 Fuchsia Project 所使用的資源。法規遵循 第三方存放區的頂層 OWNERS 會監控 公開存放區，藉此取得這些依附元件。

我們目前並沒有完善的檢查授權和產生作業的計畫 在建構及檢查程式碼期間通知檔案。我們需要研究 方法是在 fuchsia.git 存放區中，然後將邏輯通訊埠和通訊埠 複製到這個存放區

二進位檔大小監控

監控二進位檔的規模，對於長期健全度很重要 專案。Fuchsia 建構系統中提供用來監控 產生的二進位檔。再次建構這些系統 Workstations 產品不在本專案的初期階段 但最終必須加入標題

我們需要調查這些系統與目前資料庫的緊耦合程度 Fuchsia.git 建構系統 看看是否能直接與他們整合 現有的表單，或我們必須執行工作將表單分離。如果我們需要 要將工具與建構系統區隔開來，我們應著重在 工具，日後就能向其他產品整合商向外擴充。

成效測試

目前有一個專案正在執行，藉此將效能監控功能新增至 工作站產品。這項專案已著重製作 監控的樹狀結構外結構由系統使用 可用的公開 SDK 版本。我們計劃將這些測試移至工作站.git 由程式碼移出 fuchsia.git

擁有者

對 worker.git 存放區的初始協作者組合規模較小 與 fuchsia.git 的協作者組合相比有鑑於此 在本專案初期，OWNERS 檔案不會是優先順序，但 我們會持續將這些服務加到適當的目錄，以利溝通。 當我們開始將程式碼移出 fuchsia.git 時，我們會推出 OWNERS 檔案 也同樣適用於 fuchsia.git 的程式碼審查規則。

對 worker.git 存放區的貢獻將受相同的控管規範 規範 fuchsia.git 貢獻內容的相關政策，因為這類檔案將由 同一個專案

錯誤追蹤

存放區會使用現有的 Fuchsia Issue Tracker 以便追蹤錯誤使用 Fuchsia Issue Tracker 的原因在於 監控 Fuchsia 錯誤，以及開發板支援 Workstations。 則仍位於 fuchsia.git 中。頂層工作站元件 可用於一般分類，接著有幾個現有元件 來追蹤 Workstations 產品的各種功能。

成果流

為了在 fuchsia.git 以外的地方組裝 Workstations 產品 提供預建的 Fuchsia 平台供 Workstations 使用 產品。這表示我們會有兩個構件類別：構件 當中包含「平台」的元件，以及疊加於 組合最終工作站產品映像檔系統會建構 Platform 映像檔 才能供 worker.git 存放區使用，而 建構工作站元件時，會於最終產品映像檔時建構工作站 組合。構成「平台」的成果集不夠清楚 因為平台不斷演進，但工作站 其中包含 worker_session 和 Ermine 的簡易瀏覽器這項服務 需注意，我們不應提議將任何驅動程式庫開發作業樹狀結構外 新增到本提案，即使該驅動程式庫僅支援 工作站產品。

為了讓 worker.git 使用預先建構的構件，我們必須 建立 fuchsia.git 的建構工具和自動滾動式應用程式 並將構件提取至 worker.git我們或許可將其中一個 目前正在執行的建構工具，但我們尚未完整調查 可以的話

fuchsia.git 建構工具每天會執行一次，並建構 Fuchsia 平台。 還無法確切決定這個建構工具的設定方式，因為我們 並瞭解建構的內容建構工具會將所有 將適當的構件生成到該車子可以使用的位置。與 但仍需確定用於上傳這些構件的位置和機制。 成果會包含一個資訊清單檔案，內含所有依附元件 用於建立平台的不同版本包括但不限於 SDK 版本、 Experience.git 版本、Flutter 版本和 Dart 版本 Fuchsia 工具鍊版本等

該自動調節器每天會執行多次，檢查是否有新版本。 平台。多次執行可確保我們找到 各種版本 整天下來。自動駕駛工具會輪詢平台的最新版本 然後提取這些構件啟動器也會讀取資訊清單檔案 包含所有相依版本，同時也更新這些版本。這能確保 確保平台和各種依附元件之間沒有版本偏差

必要資料主要是包含檔案系統分區的檔案，例如 fuchsia.zbi 和 fvm.sparse.blk。這些檔案內含開機程序所需的所有資料 以及「基礎」和「快取」清單中的所有套件系統會 並上傳至 .far「產品套件」中，而 這個套件會包含建構元件套件所需的所有中繼資料 相符的 SDK 值根據這個中繼資料建立的套件可附加至基礎 則在「產品套件」中修改 「產品套件」中的系統分區 需同時建立一份獨立的樹狀結構外結構圖組合工具， 產品套件中封裝的特定構件清單 視新工具的 API 而定。

每日建構工具將上傳構件 存取「產品套件」指定的版本固定存放區會包含 參照，讓擲回器能夠識別 是最適合 ABI 相容性的特定版本。具體來說 這個程序目前可在這個階段外進行 提案。

組合最終產品時，建構系統應先下載 就可以透過網址辨識「產品套件」接著，系統會下載符合 將機器學習工作流程自動化(SDK 也可以隨附在「產品套件」中)。它應該 然後針對該 SDK 建構套件，為每個套件建立 metadata.far 檔案， 以及將所有必要的 blob 收集到單一位置組合工具 會把這些 blob 和套件附加至「產品套件」， 或建構成品產生的構件也應具備所有必要的 的資訊，以產生 OTA 套件。

ABI 考量事項

分別編譯 Workstations 產品與平台的做法讓我們 潛在的 ABI 不相容問題。我們必須確保 使用 SDK 發布版本編譯工作站元件： 等於或早於，但必須在個別 RFC-0002、 Workstations 產品所用平台的發布版本 為確保維持一致， 將 SDK 版本納入與平台和平台一起發布的中繼資料 worker.git 存放區將更新為使用這個版本的 SDK。

請注意，這個 ABI 考量必須延伸至 為 Workstations 產品 (例如 Flutter) 提供程式碼的花瓣 飛鏢靶。為了盡可能降低來自這些花瓣的 ABI 服務中斷風險 一開始就會嘗試這個平台，也就是說 都已通過 Fuchsia 全球整合驗證。

隨著花瓣的移動從月台表面，我們需要確保 以及與 Google 產品相容的物件為復興南瓜的花瓣 有了全域整合，我們就能在建立 平臺本身不過，我們未來將有部分依附元件 進入 Fuchsia Global Integration 之後 透過這個平台獲得的收益必須使用平台版本管理 確保我們納入的是正確版本，因此必須想辦法將 來處理過時版本

實作

利用 fuchsia.git 建構及組裝 Workstations 產品的程序 會輪到數個階段，每個階段 上一個。必須採用這個階段式做法，因為系統的各環節 我們目前正在開發樹狀結構外開發功能。

第 1 階段

讓工作站建構樹狀結構外結構的初始階段是 開發環境我們會建立 worker.git 存放區來託管程式碼。 這個存放區會包含 Bootstrap 指令碼 以便使用者快速開始運作存放區會使用 Bazel 工作區 和 Git 子模組，用於管理第三方程式碼、預先建構和廠商服務 儲存空間存放區

第 2 階段

第二階段重點在於讓建構系統設定成 Flutter 元件我們會使用保存在 fuchsia.git 中的現有 Bazel 規則 開始寫入建構規則結束狀態之後 成功建構可在執行中的 Flutter 元件上啟動 裝置。

同時，我們也針對 Flutter 元件設定規則 將探討如何使用產品組裝工具 樹狀結構外組裝完成 只要複製 儲存於 worker.git 存放區的目錄 用來建立可開機的映像檔最終狀態將是 以樹狀結構外方式組合的圖片。

第 3 階段

這個過渡期的第三階段，我們的目標是在 2013 年 以便組合整個產品其中包括設定 建構平台構件並上傳至 TUF 存放區這個建構工具將在 Fuchsia 中執行 基礎架構worker.git 存放區會推出新版本，當中包含 Autoroller。自動調度工具會更新工作站中的資訊清單檔案。 執行整合測試，並提交這項變更與 fuchsia.git 將更新版本提交至整合存放區 協調版本變更。

建構及組合的工作流程如下：

  1. 藉由更新資訊清單項目來發布新版平台 識別的平台版本和所有相依版本各版本原理 因此需要設計 可讀取和辨識的影像
  2. 使用 Bazel 和 Git 下載適當的預先建構項目和第三方存放區 來建構樹狀結構內元件
  3. 使用平台下載工具，下載 TUF 存放區
  4. 建構樹狀結構內元件。
  5. 將已建構的元件和預建元件組合成最終映像檔。

成效

這項專案不應對工作站效能產生任何影響 因為這還在建構和組裝不過，我們應該開始 我們看到 Workstations 開發人員的建構時間 大幅改善 不必自行建構平台

安全性考量

我們重複使用了許多 fuchsia.git 使用的基礎架構，但需要 確保工作站的建構和釋出方式安全無虞。我們會 與安全性和基礎架構團隊合作，共同打造安全的發布版本 和建構管道

Workstations 產品僅供參考， 確保我們仍然遵守適當的安全性通訊協定。等到 我們必須與安全性合作，才能確保 以符合安全性規定的方式建構發布內容

隱私權注意事項

現階段，隱私權方面不需考量。為了使用 Kubernetes 叢集 不會收集使用者資料的工具

測試

Workstations 產品具備一套針對各個修訂版本執行的測試。這些 例如單元測試、整合測試、e2e 測試和效能測試。 這些測試的程式碼會轉移至 worker.git 存放區 Workstations 元件的程式碼會移植到 workation.git。

這些測試的邏輯位於 Experience.git 中，因此我們以便執行測試。 因為我們會將這個存放區對應至 worker.git 程式碼所有測試使用的都是程式碼和工具， 公開 SDK，以便我們在樹狀結構外執行，但必須更新 確保可在 fuchsia.git 之外建構及執行。

每次修訂版本至 worker.git 存放區都會執行測試， 迴歸問題這需要與基礎架構團隊合作 以及如何在 CQ 建構及執行這些測試。目前的基礎架構是假設 因為存在 fuchsia.git，所以我們需要開發一個建構系統 以及各存放區版面配置

說明文件

只需要在 worker.git 中加入說明文件， 以及如何設定存放區來進行開發作業工作站發展 都會保留樹狀結構內，因此我們繼續將說明文件指向 這個工作流程

缺點、替代方案和未知

替代方法是只在 Fuchsia 樹中完成所有工作， 您將使用 SDK 提供的完整工具做法已捨棄 因為這很容易隱藏我們使用私人介面的情形。移動 樹狀結構外我們完全依賴 SDK

還有一些未知問題需要上傳到 TUF 上傳方式、上傳方式和中繼資料格式 與成果一併上傳我們認為這些細節會歸入 開始整個流程，我們會視需要修訂 RFC。