RFC-0124 - 分散式產品整合：構件說明與傳播

RFC-0124：去中心化產品整合：構件說明與傳播
狀態	已接受
領域	一般
說明	用於說明及傳播構件以進行去中心化產品整合的機制。
更小鳥	509131
作者	<lijiaming@google.com mesch@google.com schilit@google.com
審查人員	aaronwood@google.com etryzelaar@google.com wittrock@google.com atyfto@google.com marvinpaul@google.com jsankey@google.com enoharemaien@google.com schilit@google.com
提交日期 (年月分)	2021-03-30
審查日期 (年-月-日)	2021-08-30

摘要

這個機制包含兩個重要層面：

1. 說明。
2. 對成果的傳播，使這些構件可從來源存放區和其使用中的整合存放區加以識別、參照和存取。

提振精神

如「去中心化產品整合藍圖」說明文件所述，我們想要組建 Fuchsia 來源樹狀圖以外的產品。為了達成這個目標，您必須在 Fuchsia 原始碼樹狀結構外執行獨立映像檔組合工具，並提供必要的來源或預先建構的構件。Fuchsia 原始碼的樹狀結構及其他構件，包括 Zircon (Fushisia 核心) 和系統套件。各種寵物存放區可為額外元件 (例如產品專屬元件和跑者) 提供套件。

Fuchsia 原始碼構件是定期發布版本，同時，我們也會產生 Fuchsia SDK 的版本，這些版本會定期由寵物存放區匯入，並在寵物存放區的版本發布時用於產生自己的 Fuchsia 構件。

一般而言，寵物存放區的發布頻率與 Fuchsia 來源樹狀結構的發布頻率和版本的 ID 不同。寵物可能會選擇配合 Fuchsia 調整發布規則，例如為 Fuchsia SDK 的每個版本產生一個發布版本。

每個這類構件版本也可能在不同變化版本中產生，例如用於不同處理器架構的執行檔、偵錯與最佳化變化版本、由某些「穩定版」和「最新」標籤指定為區分主幹版本與穩定分支版本版本，或是建構時間功能的變化版本。

如要在與 Fuchsia 來源樹狀結構分開的整合存放區中組合來自這類構件的產品，必須將構件提供給整合存放區。此外，產品整合所需的成果必須針對每個產品版本和子類，以適當的構件版本和子類選取。

目前的產品整合程序稱為「Global Integration」。從花瓣的存放區預先建構的構件會透過「滾動式」程序，匯回 Fuchsia 原始碼樹狀結構。接著，Fusia 產品會從最新的來源修訂版本，從 Fuchsia 原始碼樹狀結構的所有構件中組合成最終建構產品，以及到達整合存放區的已固定版本，來自寵物存放區的預先建構套件。 這項程序如圖 1 所示。

圖 1 - 全域整合程序 (圖例)

這項程序有幾個缺點：

• 產品
• Fuchsia 系統的版本一律比用於建構寵物構件的 Fuchsia SDK 版本之前，因為 Fuchsia 系統是根據 Fuchsia 原始碼樹狀結構的最新來源修訂版本建構而成，但寵物產物的 SDK 是依據先前的修訂版本建構而成。
• 如果不同寵物的構件之間具有版本相容性要求 (例如 Flutter 執行元件和 aot 編譯的 Flutter 應用程式)，只有在同一個 Roller 中特別滾動這些構件，才能進行維護。
• 即使寵物成果是由產品擁有者所控制，用於產品整合的滾動式程序並不會這麼做，因為讓新版本可用於產品整合的新版本成果的滾動程序會與所有其他寵物產物的整合測試合作，且可透過失敗的任何其他產品的整合測試加以封鎖。

我們提議的去中心化產品整合流程，將對這些缺點做出的改善，使其直接了在 Fauchsia 存放區外啟用產品組件：

• 產品組合設定會保留在每項產品的專屬整合存放區中，而產品擁有者可以控管相關設定。
• 您可在與 Fuchsia SDK 相容的版本中選取 Fuchsia 構件，藉此確保產品的所有構件之間能具備 ABI 相容性。例如，類似於 RFC-0002 中規定的 ABI 修訂版本，且對應至所需的 6 週 ABI 相容性期，會以 Fuchsia 版本編號的第一個元件表示，這個元件每次建立 Fuchsia 版本分支版本時就會遞增。因此，產品中的所有構件可以對齊其建構的 SDK 發布版本編號的第一個元件。
• 您可以直接選取不同寵物存放區的構件版本，使其符合共同相容性需求，並可根據直接指定的限制升級至下一個版本，而無需為兩組構件設定專屬的擲骰子。舉例來說，您可以在等同 Flutter 和 TensorFlow 的發布版本號碼上直接選取 Flutter 應用程式和對應的 Flutter 執行元件。
• 產品可以按照自己的發布頻率，選取所有提供的構件的版本和變化版本，而不會封鎖其他選取該版本的產品。

相關人員

講師：abarth@google.com

審查者：aaronwood@google.com (Assembly)、etryzelaar@google.com (SWD)、wittrock@google.com (SWD)、 atyfto@google.com (Fuchsia Build Infrastructure)、marvinpaul@google.com (TUF Server Infrastructure@google.com (TUF Server Infrastructure)、marvinpaul@google.com (TUF Server Infrastructure, Privacy.

已諮詢：軟體推送團隊、代管 OS 團隊和基礎架構團隊成員。

社會化：除了與諮詢團隊討論外，此 RFC 的草稿已傳送至 FEC 討論郵寄清單以留言。

設計

在展示設計總覽之前，我們會介紹或釐清一些術語和概念。

術語

以下段落中的「粗體字詞」是指由前後文中解釋的字詞。

Fuchsia Source Tree 包含多個不同的 Git 存放區，這些存放區是由名為 jiri 的工具會根據設置在 integration.git 存放區中的設定，由名為 jiri 的工具組成。這些 Git 存放區最重要的一個是 fuchsia.git，但其實還有許多其他存放區，包括第三方存放區。jiri 設定也可控管是否要在來源樹狀結構的專屬部分納入預建構件。預先建構的構件本身會儲存在名為 CIPD 的儲存服務中，透過修訂版本控管功能儲存，而用來說明 CIPD 中預建構件位置和修訂版本的 jiri 設定位於 Integration.git 存放區的 Git 修訂版本控制項中。

一項定期執行的建構工作稱為 Roller，會嘗試更新 Fuchsia 來源樹狀結構中的預先建構構件版本。如果可以用更新版本的成果建構並測試 Fuchsia 樹狀結構的所有建構產品，系統會提交對 Fuchsia 樹狀結構的變更，並將構件的更新版本改為「釘選」。不同的預建構件可提供獨立的滾動器。

事實上，Fushisia 來源樹也會同時扮演 Fuchsia 產品中使用的原始碼存放區和整合存放區，其中每個 Fuchsia 產品都是從各自的組成部分組合而成。

成果是指產品組合中所使用的任何成分。這類成果會從 Source Repositories 直接取得，可以是其中一個來源項目，也可以是從存放區執行建構程序取得的建構產品。這類構件大多是預先建構的 Fuchsia 套件，但它們也構成了 Fuchsia 核心 Zircon，而且可能很快就會包含子組規格檔案。Zircon 核心和預先建構套件是預先建構的構件；Subassembly 規格檔案是來源成果。

從某個來源存放區取得的成果最終會發布到 Artifact Store。這類發布可以手動製作，也可以定期自動執行。透過任一方式，將產生的構件發布至原始碼存放區的專屬 Artifact Store。您可以前往 Artifact Store 的任何位置找到構件，而不必參照原始碼存放區，更不用參照原始碼存放區，更不用參照原始碼存放區。因此，Artifact Stores 可包括 CIPD 目錄、GCS 值區或 TUF 存放區。對此處設計的程序來說，特定種類的 Artifact Store 類型並非必要。

TUF 存放區適用於將軟體推送給 Fuchsia 裝置、新重建的套件給開發人員的 Fuchsia 裝置或模擬器，以及實際工作環境中的 Fuchsia 裝置的 OTA 更新。在已定址的儲存空間服務之外，在 Fuchsia 中使用 TUF 的特定方式特別適合儲存Fuchsia 套件。由於許多成果都是 Fuchsia 套件，因此在此設計中會偏好使用 TUF 存放區做為 Artifact Store。

「屬性」是鍵/值屬性，用於描述構件，以便系統分辨其版本和變化版本。該鍵會描述可變性維度，值則是構件所在尺寸周圍的位置。屬性會統一描述構件的版本和變化版本。在多數情況下，您不需要區分描述版本的屬性和描述變化版本的屬性。成果的發布者可以指定如下的屬性：

• CPU 架構變化版本：x64 與 arm64。
• debug 與 optimized 編譯變數。
• 構件的來源存放區修訂版本。
• 建構構件時使用的建構參數。
• 構件所用的 Fuchsia SDK 版本。
• 建構成果的語意版本。例如 Chromium 發布版本 (例如 M88.xxx)，或 Cast 發布版本 (例如 1.56.xxx)。
• 實作後，Fuchsia 系統 Artifacts 的 RFC-0002 所述 API 級別和 ABI 修訂版本。
• 花瓣粉提供的 API 級別或 SDK 版本，這不在 RFC-0002 範圍內，與系統 ABI 一樣重要。例如用於建構 Flutter 應用程式的 Flutter SDK 發布版本。

遞移屬性：部分屬性會說明構件的「遞移」屬性，因為這些屬性與建構時建構的構件的「輸入」屬性有關。舉例來說，Fushisia SDK 版本或 Flutter 版本實際上是前身構件的屬性，用於建構上述成果。預計這些轉換屬性會進一步延伸。因此，屬性值可以遞迴地包含包含鍵/值組合的物件。

依附元件屬性：構件的依附元件 (包括其版本和變化版本) 也可以用屬性表示。不過， Fuchsia 套件具有固有的特性，因此已包含其依附元件。因此，依附元件通常不會出現在 Fuchsia 構件的屬性中。

現況

在目前的全域整合程序中 (如圖 2 所示)，寵物建構程序會使用 CIPD 目錄做為其構件存放區。成果存放區會將構件保存在路徑名稱下 (在 CIPD 中稱為「package」)，與 Fuchsia 套件沒有直接關聯。CIPD 支援在「套件」的相同路徑名稱底下儲存多個「執行個體」，並將「標記」和「參考資料」附加至執行個體。變化版本中繼資訊在儲存成果的路徑名稱元件中經過編碼。版本中繼資料會在 CIPD 套件執行個體的標記和參考資料中經過編碼。產品建構程序會透過滾動式取得已固定版本的構件，並一律從寵物成果的固定版本建構產品。

圖 2 - 目前的系統結構

透過 Artifact Store 傳播延伸中繼資訊

此處提出的設計會變更 Artifact Store 的結構，以保留已發布構件的中繼資訊屬性。產品隨後可以根據屬性值指定的條件，選取適合的成果。

這項設計包含三個額外設定檔，以及三個在設定檔上運作的工具，以便與成果存放區互動。這些檔案為 artifact_groups.json，儲存在成果存放區中；artifact_spec.json 和 artifact_lock.json，會保留在產品整合存放區。如圖 3 所示，upload、update 和 fetch 工具會針對檔案和成果運作，如下所示：

1. 每個寵物或 Fuchsia 建構程序中的一組新構件群組都會在與來源存放區相關聯的成果存放區中建立新的成果群組。已發布構件的屬性會記錄在 artifact_groups.json 檔案中，這個檔案也會保存在構件存放區中。
   • Petal 建構程序會使用 upload 工具，將新發布的構件發布至構件存放區，並更新 artifact_groups.json 檔案。
2. 在產品整合存放區中，artifact_spec.json 檔案會保留用來儲存此整合存放區中產品組合成果的清單，以及哪些屬性。
   • 系統會使用 update 工具，透過整合存放區的 artifact_spec.json 檔案和 artifact_spec.json 檔案中列出的所有構件存放區中的 artifact_groups.json 檔案，選取要實際用於組合的構件組合。
3. update 工具所選的成果組合會儲存在 artifact_lock.json 檔案中。
   • fetch 工具會下載 artifact_lock.json 檔案提及的所有構件，以便提供給整合存放區中的產品建構程序。

這些工具與建構規則執行之間的關係，取決於產品整合存放區使用的特定建構系統。詳情請參閱「實作」一節。

此工具可在整合存放區中顯示多個 artifact_spec.json 和 artifact_lock.json 檔案。

圖 3 - 所有合作部分的關係

構件存放區中的邏輯結構

成果存放區中產生的構件和構件群組產生的邏輯結構如下所示：

└── artifact_groups
          |
          ├── 92d483e5-ac7d-4029-a7db-e2ee6a8365c7
          |           |
          |           ├── web_engine
          |           |
          |           └── cast_runner
          |
          └── c907ff3f-cb15-4a7f-bb79-8cc23c0ff445
                      |
                      ├── web_engine
                      |
                      └── cast_runner

每個成果群組都會以不透明名稱顯示，且每個成果會在群組中以一個可識別的名稱顯示。

這個結構、發布版本的相關屬性和個別構件的屬性會以 JSON 資料結構的形式記錄在 artifact_groups.json 檔案中，詳情請見下方說明。

構件和群組名稱的用途

JSON 資料會使用群組名稱和成果名稱，將記錄屬性與其描述的成果建立關聯。在 artifact_spec.json 檔案中，群組和構件的名稱會用來在將構件選取產品組合工作區的運算式中參照。構件名稱也會用作 fetch 工具儲存本機下載副本的檔案名稱。

但這兩個名稱都可用來指定構件在構件存放區中的儲存位置。相反地，所有構件都會儲存在其內容位址下，並將 artifact_groups.json 中每個構件的內容位址記錄為 merkle 屬性。

使用的內容位址是構件直接內容的Fuchsia「Mekle root」。部分成果 (特別是 Fuchsia 套件) 會以較晚儲存體元件 (「blob」) 的形式表示，這些元件會逐漸包含在構件的立即內容中。這些額外元件會儲存在其內容位址下，但不會在 artifact_groups.json 中明確提及。

不重複值 (變化版本)

Artifact Store 中有一些不重複的不變性。這些不變項目可藉由參照構件名稱與屬性來明確選取構件：

1. 在整個成果存放區中，群組名稱不得重複。
2. 構件名稱在每個群組中不得重複。
3. 在成果存放區中，同一群組中每個構件的屬性皆不得重複。

當將新構件群組新增至構件存放區時，upload 工具會維護這些不重複的不變體。如果 update 工具對於存取的所有 artifact_group.json 檔案都不符合其不變性，也會檢查其唯一性，並拒絕計算該更新。成果存放區本身不需要任何角色來維持這些不變。

群組名稱不透明

您很希望能在屬性值後面命名構件群組，以便讓構件儲存起來更聰明或易於瀏覽。不過，這個方法只有在「少數」屬性和一組「固定」屬性時能有效。等屬性集擴大到「許多」屬性且為一組「開放式」屬性建立名稱後，由於這些屬性組合名稱的可能排列數甚至是由一組屬性值組合而成 (即架構優先、最後或中間？)，因此從這些屬性建構名稱變得十分繁瑣。此外，閱讀這類名稱也不再是件難事，且維持不變的不重複性 (特別是跨歷史紀錄) 也相當麻煩。

因此，由於這項設計旨在支援大型且開放式屬性集，因此選擇不透明，並滿足必要的不重複性不變性，將群組名稱設為不透明。在上述範例中，群組名稱為隨機的 UUID。替代方法是使用單調遞增的填充整數。

artifact_groups.json 檔案

artifact_groups.json 檔案會列出所有群組、內含的構件，以及該成果存放區中的相關屬性。

以下範例顯示與上述構件存放區範例對應的 artifact_groups.json。屬性與成果群組相關聯，在此情況下，所有屬性都會套用至該群組中的所有構件。屬性也可以只套用至個別構件。

本設計並未指定這組屬性本身。所有屬性都是由建構和發布程序所選擇並指派，該程序會在原始碼存放區中產生成果。指派的屬性只需要維持上述不重複性不變。

{
  "schema_version": "https://fuchsia.dev/schemas/artifact_groups_schema.json",
  "version": 15,
  "artifact_groups": [
    {
      "name": "92d483e5-ac7d-4029-a7db-e2ee6a8365c7",
      "attributes": {
        "petal": "chromium.org",
        "version": "chrominum_release_20210304",
        "architecture": "arm64",
        "sdk_version": "2.20210303.3.1",
        "creation_time": "1622696983",
        "commit": "b26e44e9910608a2d0aec9b38e003a04a2da06df"
      },
      "artifacts": [
        {
          "name": "web_engine",
          "merkle":"90f67b10ded655852acb78a852ac5451486fc1e7378ce53368386244ce8f6e66",
          "type": "package",
          "attributes": {
            "runner_version": "2.20210301.1.3"
          }
        },
        {
          "name": "cast_runner",
          "merkle": "3394db36d228f4c719d055c394938c5a881ca6eea7ad3af0ad342e764cadc8b3",
          "type": "package"
        }
      ]
    },
    {
      "name": "c907ff3f-cb15-4a7f-bb79-8cc23c0ff445",
      "attributes": {
        "petal": "chromium.org",
        "version": "chrominum_release_20210402",
        "architecture": "arm64",
        "sdk_version": "2.20210303.3.4",
        "creation_time": "1622157425",
        "commit": "2dd76ad2298dfb869ef83c10b84b62485dc8a573"
      },
      "artifacts": [
        {
          "name": "web_engine",
          "merkle": "acb78a852ac5451486fc1e7378ce53368386244ce8f6e6690f67b10ded655852",
          "type": "package",
          "attributes": {
            "runner_version": "2.20210225.1.4"
          }
        },
        {
          "name": "cast_runner",
          "merkle": "19d055c394938c5a881ca6eea7ad3af0ad342e764cadc8b33394db36d228f4c7",
          "type": "package"
        }
      ]
    }
  ]
}

artifact_groups 清單中的每個群組物件都包含 3 個屬性：name 是群組名稱，artifacts 是群組中的成果清單，attributes 則是群組中所有成果共用的屬性。

只有套用至單一成果的屬性會包含在直接代表該成果的物件中。此構件的屬性會附加至群組屬性，以取得完整的 Artifact 屬性。

版本號碼為單調遞增的數字。update 工具會使用這個編號，防止意外復原至舊版 artifact_groups.json 檔案。

構件群組及其屬性的可變動性

在一般使用情況下，系統會將一組成果的每個發布版本記錄為一個新群組。因此，群組名稱、其中的構件以及其大部分屬性在概念上不可變更。而例外狀況，就是反映構件發布後所產生的成果相關資訊的屬性。舉例來說，在成果發布後執行手動測試，對成果產生了變動測試結果狀態。反映這類資訊的屬性可能會更新。

但原則上，構件群組的內容、名稱或屬性不會隨著時間而變更。因此，這很適合用於產品組合管道，但不會在建議的應用程式中採用 (請參閱下方「實作」一節)。

產品製作程序

整合存放區中的產品建構程序會在下方建立一個名為「規格檔案」的 artifact_spec.json 檔案。這個檔案會列出產品在整合存放區中組合所需的構件、取得來源的構件，以及構件屬性的模式和限制。另外，本文也會說明 Artifact Store 的類型，而且一個規格檔案中可同時存在多種不同類型的成果庫。

具體而言，預先建構的構件可自行儲存在整合存放區中，且在規格檔案中參照「local」類型的成果存放區可以參照。

整合存放區中的產品建構程序會使用 update 工具，比對規格檔案提及的所有成果存放區中的 artifact_groups.json 檔案，並運算要使用的特定成果變化版本和版本。這個組合已記錄在 artifact_lock.json 檔案中。這個檔案是要做為存放區中的來源檔案提交。

fetch 工具會讀取 artifact_lock.json 檔案，並將所有構件下載至整合存放區。這些構件不應做為來源檔案提交至存放區，不過，系統會根據從 artifact_groups.json 檔案取得的內容位址，在 artifact_lock.json 檔案中辨識成果。這可確保 artifact_lock.json 的修訂內容能完全決定提供給建構作業的構件內容，因此就 artifact_lock.json 檔案中選取的構件而言，產品組合版本具有密封且可重現的特性。

實作

本文提出的設計將先實作，以將工作站產品整合項目移至另一個存放區。

artifact_spec.json 所需的詳細資料，以及系統如何針對 artifact_groups.json 檔案進行處理，以便產生 artifact_lock.json 檔案；請參閱「其他 RFC」。

遷移現有的寵物和產品

只要 Fuchsia 原始碼樹狀結構中 (透過整合.git 設定) 仍需要花瓣的預先建構資料，這些套件必須同時上傳至 CIPD，以供 Fuchsia 原始碼樹狀結構中的 Wichsia 原始碼規則以及用於樹狀產品以外的構件存放區使用。最後，Fchsia 原始碼樹狀結構中將不再需要使用一些預先建構的寵物資料，而上傳至 CIPD 可能會停止。

我們無意取代使用 jiri 設定 Fuchsia 原始碼本身的機制，因為所有 Fuchsia 平台構件以及 SDK 和部分產品會繼續以 Fuchsia 原始碼樹狀結構建構。

構件存放區

工作站及其寵物實作將使用 TUF 存放區做為構件存放區。TUF 存放區的 targets.json 檔案中唯一的項目適用於 artifact_groups.json 檔案。成果本身會儲存在由 TUF 伺服器基礎架構維護的 TUF 伺服器基礎架構維護的內容中，而對應的 blob 位址則記錄在 artifact_groups.json 檔案中。

此外，構件也可以列在目錄和構件名稱的 targets.json 中，但在這項設計中不需要。(之所以提及這點，是因為這裡提到了記錄完整性，因為過去有人預期會有 targets.json 項目時，此作業就會完成。請參閱下方的替代方法一節)。

Fuchsia 套件結構依附元件

此處提議的三項工具會與構件存放區互動 (上傳、更新、擷取) 在 Fuchsia 套件中運作，因此會假設 Fuchsia 套件的結構。具體來說，假設有一個 Fuchsia 套件包含包含內容位址的 meta.far blob (以「merkle roots」表示)，而這些 blob 也屬於套件的其他 blob。meta.far 中參照的 blob 清單是透過 Fuchsia SDK 提供的工具取得，因此構件儲存空間工具 (上傳、更新、擷取) 不會依附於 meta.far 的內部結構。

工具與建構規則的關係

upload、update 和 fetch 工具與建構規則執行之間的關係，取決於原始碼存放區中的特定建構系統、產品整合存放區，以及要執行建構作業的結構。

建構系統完成建構後應執行 upload 工具。

通常，update 工具應在建構規則外使用，然後再執行建構。

fetch 工具可在建構規則執行前使用，或者如果建構系統在建構系統執行過程中支援該工具。對工作站使用 bazel 做為建構系統，支援設定名為「工作區規則」的輸入檔案。

工具執行檔的名稱

upload、update、fetch 工具最終可能以其他名稱實作，而非此設計中使用的概念名稱。具體來說，這些程式庫可能會以外掛程式的形式導入至 ffx 工具，或做為由 bazel 建構規則產生的工具。初始原型會實作這些程式碼，做為名為 artifact_upload.py、artifact_update.py 和 artifact_fetch.py 的 Python 指令碼。

檔案語法

artifact_groups.json 檔案的語法是由下列 JSON 結構定義指定。artifact_spec.json 和 artifact_lock.json 檔案的 JSON 結構定義檔以個別 RFC 記錄。

{
  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "$id": "https://fuchsia.dev/schemas/artifact_groups_schema.json",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "contents",
    "schema_version",
    "version"
  ],
  "properties": {
    "schema_version": {
      "type": "string"
    },
    "version": {
      "type": "integer"
    },
    "artifact_groups": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "name": {
            "type": "string"
          },
          "attributes": {
            "type": "object"
          },
          "artifacts": {
            "type": "array",
            "items": {
              "type": "object",
              "additionalProperties": false,
              "required": [
                "name",
                "merkle",
                "type",
              ],
              "properties": {
                "name": {
                  "type": "string"
                },
                "merkle": {
                  "type": "string"
                },
                "attributes": {
                  "type": "object"
                },
                "type": {
                  "type": "string"
                }
              }
            }
          }
        }
      }
    }
  }
}

檔案語意

此處說明 artifact_groups.json 的檔案格式語意。我們另以獨立 RFC 記錄 artifact_spec.json 和 artifact_lock.json 的詳細語意。

{
  "schema_version": SCHEMA_VERSION,
  "version": VERSION,
  "artifact_groups": [
    ARTIFACT_GROUP,
    ...
  ]
}

SCHEMA_VERSION

指出 artifact_groups.json 的 JSON 結構定義網址的字串。

版本

代表 artifact_groups.json 版本號碼的整數。發布新版本後，這個數字就會增加。

ARTIFACT_GROUP

每個 ARTIFACT_GROUP 都是一個物件，其格式如下：

{
  "name": NAME,
  "attributes": ATTRIBUTES,
  "artifacts": [
    ARTIFACT,
    ...
  ]
}

NAME

提供參照這個構件群組的方法的字串。

屬性。

發布者定義的物件。

古物

每個 ARTIFACT 都是一個物件，其格式如下：

{
  "name": NAME,
  "merkle": MERKLE,
  "type": TYPE,
  "attributes": ATTRIBUTES
},

NAME

包含此構件名稱的字串。

梅克勒

構件的 Merkle 根字串。

類型

包含此構件類型的字串。如果 TYPE 為 "package"，則其 Merkle 根目錄所參照的 blob 中即是 fuchsia 套件的 meta.far，而 meta.far 中參照的 blob 一律會與 Meta.far blob 一起處理。否則，成果只會包含列出 Merkle 的單一 blob。

屬性

與上述定義的 ATTRIBUTES 類似的物件。請在這裡定義構件專屬的屬性。

安全性注意事項

此 RFC 中的設計不會變更現有實施者之間的信任模型。這個機制只會變更儲存空間結構，而不會變更使用構件存放區的發動者，或是演員與構件存放區之間的信任關係。

信任模式

如同使用 CIPD 做為構件存放區的現況，產品建構程序需要信任構件存放區。這項信任是依據存取權控管和驗證，在構件儲存至儲存庫後套用至寵物和 Fuchsia 建構程序，並且仰賴建構基礎架構和環境來解析已設定的構件存放區名稱來存取正確的構件存放區。

一旦建立更多構件商店和產品整合存放區，便需要評估這些存放區的信任基礎，並相應的評估組合產品的可信度。

日後，系統可能會建立現行用途上方的其他機制，例如對 TUF 存放區中的簽名進行驗證。這項機制設計的機制可以支援相關資訊，根據評估可信度的心態來傳播相關資訊，但此類資訊的建立方式互不相關。

關於 TUF 簽章，請特別注意，這類簽名只提供佐證代管成果存放區的可靠度的證據。光是評估從來源取得的構件是否可信，並不會完全取決於簽署金鑰的控制權、產生構件的建構程序可信度，以及建構程序用來做為輸入內容的傳輸來源和工具的可信度。如果是目前用於 Fuchsia 產品的 TUF 實作 (這會簽署任何上傳至維護存放區的服務成果)，也會依附於 ACL 的完整性和可讓用戶端存取該服務的驗證機制。

多個寵物建構程序發布至同一個構件儲存庫

建議發布來源存放區時，不要共用構件存放區，因此無論其建立方式為何，這類存放區都不必與伺服器共用信任關係。其中一個例子是 TUF 實作，發布者不需要共用簽署金鑰。

此外，將多個寵物建構程序發布至同一個構件存放區，也會引進多個潛在入侵風險。其中一個例子是，發布者可能會覆寫另一個發布者發布的成果。不過，這不在這個 RFC 的涵蓋範圍內，因為在此 RFC 中，發布至構件存放區的所有寵物建構程序是由相同的機構營運，因此可以妥善協調處理。如果我們想將這項功能擴展至多個機構 就必須設計不同的協調模型

效能

隨著 artifact_groups.json 檔案中的項目數量增加，找出符合所有必要屬性的群組所需的時間也都會增加至少線性。如果構件有限制，就可能是線性變形，因為更新工具需要彙整多個 artifact_groups.json 檔案才能進行選擇。成果發布者可能需要移除過舊的構件群組，以改善用戶端更新工具的效能。

選取構件的下載時間可能會大幅適用於大型產品。這和現狀也大同小異。這裡顯示的設計具有以下優勢：透過 fetch 工具，將特定產品在特定時間預先建構的構件下載至任何整合存放區時，此設計具有優勢。在目前的全球整合中，您必須在 jiri update 期間下載所有已知產品的預先建構構件聯集。

隱私權注意事項

唯一儲存在成果存放區的新資料是 artifact_groups.json 檔案。構件存放區的發布者不一定能在 artifact_groups.json 檔案中發布 PII。

測試

工具使用的程式庫會經過單元測試，例如比對 artifact_spec.json 檔案中的屬性模式和 artifact_groups.json 檔案。

針對以執行檔操作的工具操作，會在本機保留的黃金檔案中執行整合測試。

對端對端測試而言，自己的存放區中會有「Hello World」產品，這個產品可以持續執行機器，並可監控是否故障。

缺點、替代與不明

使用其他類型的構件儲存庫

除了 TUF 之外，還有其他可以使用的構件存放區。例如：

• CIPD
• 靜態 HTTPS 伺服器
• GCS 值區
• Git 存放區。

系統可以在所有構件存放區中，建立在名稱底下為其內容位址下的構件，並採用與上述實作中使用的 TUF 存放區相同的方式，在 artifact_groups.json 檔案中維護適當的結構來找出其內容位址底下的構件。

每個版本的 TUF 存放區

此設計先前版本採用的另一個替代做法，是每個構件版本的 TUF 存放區。upload 工具不會為版本的所有構件建立群組，而是會建立新的 TUF 存放區來代管構件。已知的查詢存放區包含記錄屬性的 artifact_groups.json 檔案。叢集名稱中包含每個構件群組的存放區名稱，而不是群組名稱。

此方法的優點是能夠支援使用臨時套件的產品，這類套件只有在首次使用時才會提供給裝置。除了在產品組合中將套件納入這類發布存放區之外，存放區也可以納入產品中的套件來源，以便在執行階段解析套件網址。

由於這類產品目前不存在，且在裝置和 TUF 基礎架構中採用目前的軟體推送機制，卻一直無法證明能以此方式在實際工作環境中使用，因此我們預計還會在實現這個目標前進一步發展。因此，我們強烈希望不受限於軟體推送目前的狀態。同樣地，TUF 基礎架構也不適合用來處理大量的 TUF 存放區。

TUF 存放區的 targets.json 中列出的所有構件

一開始，所有構件 (特別是所有 Fuchsia 套件) 都會列在 TUF 存放區的 targets.json 檔案中，而在一個版本中分組構件的目錄是實際包含 TUF 存放區目標的目錄。該資訊與 artifact_groups.json 中記錄的資訊重複且沒有用途，因此為求清楚，並已捨棄此內容，並規避對 targets.json 所規定以外的檔案大小限制，只存放在 targets.json 中的檔案。

不明

對於所呈現設計的應用方式，目前尚有尚未回答的問題。

• 這種機制是否也能套用至 Fuchsia SDK？Fuchsia SDK 是建立寵物元件和樹狀產品的先決成果，就像建立產品的先決成果一樣，而且必須根據描述兩者的屬性，以非常類似的方式選取。因此，這個問題會表明寵物建構程序是否應在 artifact_spec.json 檔案中宣告 SDK 的使用方式，以及產品建構程序是否應在其 artifact_spec.json 檔案中納入 Fuchsia SDK。
• 這種機制是否也能應用在寵物 SDK (即寵物用的 SDK 是提供給其他寵物的 SDK，例如 Flutter SDK)？這項操作不必啟用去中心化產品整合功能，但可能會簡化產生的分散式建構程序。舉例來說，只要在寵物存放區的鎖定檔案中檢查擷取的 Flutter SDK 版本，上傳工具就能找出已上傳構件的正確 Flutter SDK 版本屬性值。
• 這項機制是否也能用於發布已打造的產品？在工作站實作中，Fuchsia 工作站產品可發布至構件存放區。這個上傳的產品稍後可用於差異化組合。
• 說明機制是否可以遞移性地為建立產品時涉及的所有二進位構件建立二進位檔透明度、返回產品內含的預先建構構件、用來組合產品的工具的預先建構構件、建立預建構件的工具等等。

說明文件

本文件是初步文件，會提供工具 並會提供說明頁面工作站存放區設定會做為藍圖與示範，供後續使用。

優先藝術與參考資料

其他作業系統的產品整合通常來自來源樹狀結構，且使用預先建構的特性較少，因此在存放區之間同時傳播多個變化版本和這類預先建構版本的要求較少。

「建構系統」只要在目前版本重新建構依附元件，即可在目前套用的建構參數決定的變數中，「選取」依附元件的相容「版本」。這裡提出的設計可以理解是建構系統的一般化，以非同步方式運作和發布。

相關文件

• 去中心化產品整合 Fuchsia 發展藍圖項目。
• 平台版本管理 RFC
• 獨立圖片組件 RFC
• 工作站外遷移 RFC
• 樹外 Bazel SDK RFC 草稿
• 去中心化產品整合、構件選擇規格 RFC 草稿
• 從子組裝完成的產品 RFC 草稿

附錄

圖 4 - 全球整合圖圖例