跳到主要內容

基礎架構

本頁概述 conda-forge 的基礎架構，也就是由 conda-forge 貢獻者和第三方供應商維護的各種組件的說明，這些組件共同構成了 conda-forge 運作的基礎。

我們先從 conda-forge 本身維護的不同 Github 儲存庫開始，然後描述這些儲存庫中可用的管理命令，即所謂的 管理網頁服務，接著是 CI 服務，也就是用於共同建置和維護套件的第三方供應商。之後，我們將轉向描述 編譯器與執行期中套件建置環境的某些方面，以及關於上傳到套件伺服器的詳細資訊。

接著，我們將了解建置套件的過程如何與基礎架構的不同部分互動。

最後，我們以簡要的 相關實體清單 作為結尾。

儲存庫​

暫存食譜​

此儲存庫是 conda-forge 的閘道，使用者可以在此提交新的食譜，一旦經過審核並接受，將會產生新的 feedstock 和團隊。您可以在暫存流程中找到提交新套件食譜的詳細指南。

暫存食譜的剖析​

recipes/ 包含一個或多個帶有使用者提交食譜的子目錄。大多數情況下，一次只會提交一個食譜，但如果存在多個子目錄，build_all.py 腳本將按照正確的順序 (拓撲排序) 建置它們，以便滿足依賴項。

.ci_support 包含 conda-build YAML 設定檔，但在這種情況下 (與 feedstocks 相比)，您還會找到一些腳本

  • build_all.py: 按照正確的 (拓撲排序) 順序呼叫 conda-build。
  • compute_build_graph.py: 透過提供包含所有已提交食譜的工作圖來支援 build_all.py。

.ci_support 中包含的 YAML 檔案是最小化的，並且不像您在 feedstocks 中找到的那些檔案那樣渲染。相反，conda-build 將採用這些檔案，並在執行時將它們與來自 conda-forge-pinning 的釘選結合。另請注意，staged-recipes 僅針對 x64 建置。對其他架構的支援只能在提供 feedstock 後才能完成。

  • Linux: linux64.yaml 加上 CUDA 變體。
  • macOS: osx64.yaml。
  • Windows win64.yaml。

目錄 .scripts 大致包含與 feedstock 中用於 CI 管道的 shell 腳本相同的腳本。但是，由於 staged-recipes 不支援重新渲染，因此這些腳本會手動保持同步，並且常見到一些差異。

工作流程​

在 staged-recipes 上運行的主要工作是 conda-build 工作，它在每個 PR (以及推送到 main) 上運行，以檢查食譜是否正確建置套件。這些工作在 Azure Pipelines 上運行，定義於 .azure-pipelines/ 中。

feedstock 的實際建立在 conda-forge/admin-requests 中運行。

其他工作流程可協助使用者正確設定其食譜。它們對 PR 中的事件做出反應

  • automate-review-labels: 更新 PR 標籤以簡化審核和請求協助。
  • linter: 一般食譜檢查加上一些 staged-recipes 特定的檢查，例如不編輯範例。

外部服務也連接到 staged-recipes

  • @conda-forge-admin 機器人 (部署於 webservices) 將檢查食譜並根據食譜的內容在 PR 中提供提示。

Feedstocks​

  • ⚙️ 部署於 Github 儲存庫中
  • 🔒 有權限存取 Azure Pipelines、Github Actions、Anaconda.org (cf-staging)
  • 🔐 可能透過 admin-requests 有權限存取 Travis CI、Cirun (WIP)
  • 🤖 與 admin-migrations、admin-requests、autotick-bot 和 webservices 整合。

Conda-forge 有數千個 feedstocks。每個 feedstock 託管一個食譜以及必要的管道、支援腳本和設定元數據。

feedstock 的內容已明確指定。只有兩個位置由使用者管理

  • recipe/: 包含用於建置套件的 conda-build 指示。它至少需要一個 meta.yaml 檔案，這也是可選的 conda_build_config.yaml 通常所在的位置。
  • conda-forge.yml: 這是 feedstock 設定檔。
警告

您絕不應該手動編輯未在上面列出的檔案！變更將在下一次 feedstock 重新渲染中被覆蓋。

將這兩個來源與一些外部組件結合，conda-smithy 將產生 (渲染) feedstock 的內容。許多目錄的命名方式都是如此，因為它是外部服務 (例如 Azure) 請求的。但是，一些 conda-smithy 獨有的目錄值得討論

  • .ci_support/: 包含渲染後的 conda_build_config.yaml 檔案，透過 -m 標誌傳遞給 conda-build。此處的每個檔案都對應於 CI 建置矩陣中的一個工作。
  • .ci_support/migrations/: 特殊的 YAML 檔案，指示 conda-smithy 如何更新 .ci_support/*.yaml 檔案。這些遷移檔案通常由 autotick-bot 基礎架構放置在此處，並在遷移被認為完成後移除。
  • .scripts/: 支援您可以在 CI 管道和本地偵錯工具中找到的步驟的通用邏輯和程式碼。
  • build-locally.py: 一個 Python 腳本，用於在您的機器上偵錯食譜，大致相當於 CI 管道中完成的操作。
了解更多 (WIP)
  • 重新渲染 feedstock
  • 建議工作流程

feedstocks 單一儲存庫​

一個包含所有 feedstocks 作為子模組的單一儲存庫。

feedstock-outputs​

此儲存庫是 feedstock 名稱和它們產生的套件 (成品) 的註冊表。

其主要目的是為驗證伺服器提供允許清單，以防止惡意跨 feedstock 建置，儘管它也是 feedstocks <-> packages 的資訊地圖，該地圖在網站的套件區段中公開。

cdt-builds​

這個特殊的儲存庫為 conda-forge 建置核心依賴樹套件 (僅限 Linux)。它不使用 feedstock 自動化機制。相反，它有自己的 Azure Pipelines 工作流程和文件完善的 README。

msys2-recipes​

這是 Anaconda 上舊社群食譜儲存庫的分支，其中包括 msys2/ 目錄下的 msys2 食譜。另請注意 common-scripts/ 資料夾中的支援腳本。

網站​

目前的 conda-forge.org 是一個靜態生成的網站，發佈到 Github Pages。

文件使用 Docusaurus 建置，原始碼檔案位於儲存庫的 docs/ 目錄中。

如果您發現任何錯字、錯誤、不清楚的解釋或可以涵蓋的新主題，您可以建議變更文件。如需更多詳細資訊，請參閱改善文件。

除了靜態文件外，網站還提供有關 conda-forge 當前狀態以及套件到 feedstocks 的映射資訊。

元數據儲存庫​

這些儲存庫主要持有 conda-forge 生態系統其他部分使用的元數據。

conda-forge pinning​

託管 conda-forge 的全域釘選和正在進行的遷移。

套件範圍的依賴項釘選定義於 conda_build_config.yaml，位於 conda-forge/conda-forge-pinning-feedstock 中。

有關 conda-forge 範圍廣泛的套件釘選的更多資訊，請參閱全域釘選的套件。

如果您認為需要推進釘選，請在那裡開啟一個 PR 和/或一個 issue。有關更新全域釘選套件的更多資訊，請參閱更新套件釘選。

conda-forge-repodata-patches​

此儲存庫建立 Anaconda.org 使用的 repodata.json 補丁，以修改來自已發佈套件的元數據。

conda-forge-ci-setup​

這個特殊的 feedstock 提供一個套件，該套件定義了安裝和設定跨供應商的通用 CI 設定的邏輯。

regro/cf-graph-countyfair​

這是 autotick-bot 使用的圖形數據。

建置圖形的邏輯由 cf-scripts 提供。

docker-images​

此儲存庫建置 Docker 映像檔，用於在所有 Linux 建置上提供統一的系統。

程式碼儲存庫​

這些儲存庫持有定義行為的程式和其他程式碼。但是，它們的動作通常不是在這裡觸發，而是由 conda-forge 生態系統的其他部分使用。

Smithy​

這是主要的 feedstock 建立和維護工具。

它的大部分使用由我們的基礎架構自動化

  • Feedstock 建立和服務註冊於 staged-recipes
  • 在 webservices 上由 conda-forge-admin 完成重新生成 (重新渲染)、檢查和提示

但是，您也可以在本地或類似 forge 的部署中使用它。對於本地偵錯，您會發現這些命令很有用

  • conda-smithy rerender
  • conda-smithy recipe-lint

Smithy 包含 conda-forge 的維護程式碼，conda-smithy 命令列工具和管理網頁服務使用它。

conda-forge/conda-smithy 是回報錯誤的正確儲存庫，適用於

  • 重新渲染流程
  • 食譜檢查器
  • CI 支援工具

conda-smithy 也包含命令列工具，如果您從命令列手動重新渲染 (請參閱重新渲染 feedstocks)，則應使用該工具。

Smithy 可以用於超出 conda-forge 的目的之外的用途。例如，它可以用於為非 conda-forge 基礎架構設定自託管 Azure 代理程式。(您也可以考慮使用 Azure 虛擬機器規模集代理程式，它們的運行成本可能比永久活動代理程式更低。)

網頁服務​

提供 conda-forge 網頁服務的 Heroku 應用程式位於 conda-forge/conda-forge-webservices。請注意，應用程式提供的程式碼邏輯位於 Smithy 儲存庫中。

因此，關於服務功能的錯誤或建議應在 conda-forge/conda-smithy 的 錯誤追蹤器 中開啟。

regro/cf-scripts​

autotick-bot 背後的程式碼和邏輯。

自動化維護​

這些組件以自動化方式執行動作，可以是透過特定事件觸發，也可以作為迴圈的一部分持續執行。

admin-migrations​

此儲存庫託管 24/7 運行的工作流程。其工作是取得一個自動化迴圈，其中新增了一些維護任務。其主要使用者是核心團隊。

admin-requests​

此儲存庫託管主要在使用者啟動的動作觸發時運行的工作流程。這通常透過 PR 完成，一旦獲得批准，PR 會被合併並觸發請求的動作 (將套件標記為損壞、封存 feedstock 等)。

它還執行為已合併到 conda-forge/staged-recipes 中的食譜建立新 feedstocks 的工作。create_feedstocks 工作流程 每小時運行數次，以在 conda-forge 組織上建立新的 feedstock 儲存庫。核心邏輯在 Python 腳本 .github/workflows/scripts/create_feedstocks.py 中定義。

autotick-bot​

注意

較舊的儲存庫 regro/autotick-bot 已不再使用；機器人現在直接在 regro/cf-scripts 中運行。

webservices​

此網頁應用程式驅動多項服務，例如

  • @conda-forge-admin 機器人及其 @conda-forge-admin, please ... 命令
  • 從 cf-staging 到 conda-forge 的驗證 (加上複製)
  • 狀態監控

管理網頁服務​

conda-forge 正在 Heroku 上運行一個名為 conda-forge-webservices 的網頁服務。

以下服務預設在 feedstock 上運行

  • 它將檢查 PR 中的食譜，並回報食譜是否處於良好狀態。
  • 當維護者被新增到食譜時，每位維護者都將被新增到團隊，並獲得 feedstock 的推送權限。

網頁服務也監聽 issue 和 PR 評論，以便您可以要求完成以下服務

@conda-forge-admin, please rerender​

在 feedstock 的 PR 中輸入上述短語將重新渲染 feedstock 並將變更推送到您的 PR。請務必勾選位於 PR 右側邊欄底部的「允許維護者編輯」按鈕。如果您在 issue 的評論中輸入此短語，機器人將建立一個新的 pull request，並完成請求的重新渲染。

@conda-forge-admin, please add noarch: python​

在 feedstock 的 PR 或 issue 中輸入上述短語將在建置中新增 noarch: python 並為您重新渲染 feedstock。

@conda-forge-admin, please lint​

在 feedstock 的 PR 中輸入上述短語將再次檢查 PR。

@conda-forge-admin, please update team​

在 issue 中輸入上述短語將更新 feedstock 的團隊。這通常是自動完成的。

@conda-forge-admin, please restart ci​

在 feedstock 或 staged-recipes 的 PR 中輸入此命令將關閉然後開啟 PR，導致所有 CI 建置重新啟動。

@conda-forge-admin, please ping team​

在 feedstock 或 staged-recipes 的 PR 中輸入此命令將使管理機器人 @-提及與儲存庫相關聯的團隊。此命令對於尚未成為 conda-forge 成員且因此無法 @-提及 staged-recipes 團隊進行 PR 審核的人員很有用。

@conda-forge-admin, please ping conda-forge/​

在 feedstock 或 staged-recipes 的 PR 中輸入此命令將使管理機器人 @-提及各自的團隊。此命令對於尚未成為 conda-forge 成員且因此由於一般的 GitHub 限制而無法 @-提及某人的人員很有用。

@conda-forge-admin, please rerun bot​

在 PR 評論中輸入此命令將在該 PR 中新增 bot-rerun 標籤。此標籤將導致發布遷移和版本更新的 auto-tick 機器人關閉當前 PR 並重新發布它。將此標籤新增到非機器人發布的 PR 將無效。

@conda-forge-admin, please add bot automerge​

在 issue 的標題或評論中輸入此命令將指示管理機器人開啟一個 PR，啟用自動合併來自 auto-tick 機器人的通過 PR。此功能目前處於實驗階段。您可以在此處找到更多詳細資訊。如有任何回饋、錯誤和/或問題，請在 regro/cf-scripts 上開啟 issue！

@conda-forge-admin, please remove bot automerge​

在 issue 的標題或評論中輸入此命令將指示管理機器人開啟一個 PR 以停用 automerge，撤銷 please add bot automerge 命令。

@conda-forge-admin, please add user @username​

在 feedstock 的 issue 標題中輸入上述短語將建立一個 PR，將給定使用者新增到 feedstock。然後，維護者或核心成員可以合併此 PR 以新增使用者。請勿修改此 PR 或調整提交訊息。此 PR 旨在跳過建置套件。

使用此命令

這不是開始協助處理 feedstock 的建議方式。如果您有興趣協助處理特定食譜，最好從提交包含新版本或修復的 PR 開始。這樣，您可以獲得關於您工作的回饋，並了解一些 feedstock 的歷史背景。

一旦您與維護者建立了工作關係，您可以要求他們將您新增到 feedstock 團隊。然後他們可以使用此命令將您新增到團隊。關於如何新增新維護者沒有任何官方要求，因此可能需要一段時間才能就何時新增新維護者達成共識。不要讓這阻止您做出貢獻！

任何人都可以自由開啟 PR！！！感謝您的時間和努力！！！

@conda-forge-admin, please update version​

在 feedstock 的 issue 標題中輸入上述短語將請求機器人檢查是否有任何新版本可用。如果有，它將開啟一個包含所需變更的 PR。請注意，機器人可能會先開啟一個僅包含部分變更的 PR。其餘內容將在幾分鐘後的後續提交中新增。

CI 建置服務​

在這裡，我們描述 conda-forge 建置的 CI 服務的常見問題。

Azure Pipelines​

Azure 用於建置 Windows (原生 x86_64)、macOS (原生 x86_64)、Linux (原生 x86_64、模擬 ARMv8 和 IBM Power8+) 的套件。Azure 上的建置佇列遠大於所有其他供應商。Azure 建置的最長持續時間為 6 小時。

若要查看 Azure 上的所有建置，請訪問 https://dev.azure.com/conda-forge/feedstock-builds/_build。

重新啟動建置​

目前 Azure 無法同步 GitHub 使用者。若要重新啟動建置，您可以從 GitHub 檢查介面重新啟動。如果這樣無效，關閉/開啟拉取請求將會啟動新的建置。您也可以使用網路服務命令 @conda-forge-admin, please restart ci。

TravisCI (IBM Power 8+, ARM)​

TravisCI 用於為 IBM Power 8+ 和 ARM 建置套件。合併 staged-recipes 拉取請求後，可能需要強制同步您在 TravisCI 中的儲存庫，才能看到重新載入和取消按鈕。若要執行此操作，請造訪 https://app.travis-ci.com/account/repositories 並點擊「同步帳戶」按鈕。

啟用 Travis​

TravisCI 僅適用於在原生 Linux aarch64 和 ppc64le 上建置 recipe。

若要啟用建置，請將以下對應的行新增至 feedstock 根目錄中的 conda-forge.yml。

provider:
  osx: travis
  linux_ppc64le: travis
  linux_aarch64: travis

對於 IBM Power 8+ 和/或 ARM 建置，請透過拉取請求將您的 feedstock 名稱新增至 此處 清單。

GitHub Actions​

我們使用 GitHub Actions 重新渲染 feedstocks，並執行我們的拉取請求自動合併服務。我們目前不支援在 GitHub Actions 上進行建置。

網路服務背景工作​

webservices Heroku 應用程式會調度至 GitHub Actions 以執行運算密集型背景工作，包括重新渲染、版本更新和自動合併工作。GitHub Actions 執行發生在 conda-forge-webservices 儲存庫。這些執行使用 webservices-dispatch-action Docker 容器 進行某些操作。此容器標記有最新的 webservices 版本。

自動合併​

我們的自動合併服務透過 GitHub Actions 在 conda-forge-webservices 儲存庫 中執行。

如果拉取請求滿足以下兩組條件之一，則會自動合併

  1. 來自 regro-cf-autotick-bot、標題中有 [bot-automerge]、所有狀態皆通過，且 feedstock 允許自動合併
  2. 具有 automerge 標籤且所有狀態皆通過。

對於來自 regro-cf-autotick-bot 的拉取請求，如果您要編輯拉取請求，移除拉取請求標題中的 [bot-automerge] 標籤可能會很有用。

略過 CI 建置​

若要略過特定提交的 CI 建置，請在提交訊息中放入 [ci skip] ***NO_CI***。

相關連結

第三方使用我們的 CI 服務​

由於 conda-forge 在開源社群中的地位，因此增強了對某些 CI 服務的存取權。此存取權是社群資源，委託給 conda-forge 用於建置套件。因此，我們無法在我們的任何 CI 服務上的 feedstock 中支援第三方或「非標籤」CI 工作。如果我們發現此類使用情況，我們會禮貌地要求維護人員糾正情況。如果情況無法糾正，我們可能會採取更嚴厲的行動，包括封存 feedstocks 或將維護人員從組織中移除。

外部執行器（適用於 GitHub Actions）​

當目前的基礎架構無法滿足 feedstock 維護人員的 CI 需求時，conda-forge 提供了一種透過 Cirun 貢獻/贊助外部執行器的方法。這些外部執行器（即專用執行器）可用於在一個或多個 feedstock 上建置套件，具體取決於維護人員。它們是特定雲端或一組雲端上的執行器，即促進外部執行器的佈建基本上是承諾贊助在 支援的雲端 上佈建臨時虛擬機器。以下描述了相同的流程

  • 請與 conda-forge/core 聯繫以討論您的使用案例。這可以透過相關 feedstock 中的 issue 或透過 Zulip 完成。
  • 討論完成後，請與 conda-forge/core 成員分享支援雲端的憑證，以便將其新增至 conda-forge 的 Cirun 帳戶，或者使用者可以為現有的 conda-forge 雲端帳戶贊助雲端點數。
  • 在 conda-forge/.cirun 中新增執行器的虛擬機器組態，在 .access.yml 中新增政策條目，以允許 feedstock 存取執行器。
  • 在您的 <package-feedstock>/recipe/conda_build_config.yaml 中的 github_actions_labels 下新增以上定義的標籤，並重新渲染 feedstock。請參閱以下連結以取得一些範例。

完成以上步驟後，feedstock 維護人員應該能夠使用已定義的執行器來執行 feedstock 儲存庫的 CI 工作。

外部執行器使用範例​

Pytorch 目前在 Azure 上使用透過 cirun 佈建的自訂 Windows 執行器，以在 Windows 上建置。這是由 Prefix.dev 贊助的。以下是相關的拉取請求

編譯器和執行時期​

conda-forge 為各種語言和/或系統（例如，C、FORTRAN、C++、CUDA 等）建置和維護自己的編譯器集。這些編譯器用於我們所有的 CI 建置中，以建置 conda-forge 發佈的幾乎所有成品。

此編譯器基礎架構除了建置所有內容外，還扮演著至關重要的角色，那就是確保套件彼此保持相容。這是因為編譯後的套件具有所謂的 應用程式二進位介面 (ABI)，以及編譯器基礎架構中的變更可能會破壞此 ABI，導致崩潰、誤算等問題。一般來說，使用一致的編譯器版本可以大大降低 ABI 損壞的風險。

編譯器通常會努力在不同版本之間保持 ABI 相容性，這表示將同一目標的不同版本編譯器產生的成品組合在一起，可以正常運作而不會出現問題。由於 ABI 的性質（即軟體和硬體之間龐大的介面，具有無數的邊角案例），在不同編譯器版本之間引入某些特定方面的非預期變更仍然會發生，儘管在實務上這不會導致廣泛的問題。

相反地，當編譯器有意變更 ABI 時（例如 MSVC 在目前涵蓋 VS2015-VS2022 的 vc14 系列之前的每個版本都這樣做），每個 編譯後的套件都需要針對新的 ABI 重新建置，並且不能與舊 ABI 的建置混合使用。雖然現在不太可能發生，但在原則上，編譯器堆疊中的重大基礎架構改版也可能同樣迫使完全重新建置。

這種大規模的變更 – 需要重新建置 +/- 所有 conda-forge – 需要付出很多努力，但幸運的是，近年來不需要進行這種完全重新建置，而我們設法進行了破壞性較小的編譯器升級。

然而，大規模的 ABI 損壞仍然有可能發生（例如，MSVC 正在計劃 vc14 之後的 vNext），因此我們保留了針對這種情況的政策。雖然我們沒有對 ABI 相容編譯器世代的支援做出任何正式承諾，但我們歷來根據以下（非約束性）原則維護它們。

  • 各種語言和平台的目前編譯器和版本的權威來源是 conda_build_config.yaml，位於 conda-forge/conda-forge-pinning-feedstock 中，如 全域釘選套件 中所述。
  • 我們不提供任何形式的長期穩定性/特定編譯器世代支援。
  • 我們會定期以特別的方式升級它們，只要我們有時間和精力這樣做。請注意，由於我們強制執行執行時期約束的方式，這些編譯器升級不會破壞現有的套件。但是，如果您在 conda 之外使用編譯器，則可能會遇到問題。
  • 當即將發生 ABI 不相容的編譯器變更時，我們通常會以公告的形式發出通知。請注意，這些變更需要一些時間才能完成，因此如果您需要準備，通常會有時間準備。
  • 我們在考慮編譯器遷移時會考慮到的一些標準包括
    • 對生態系統的破壞程度，
    • core 團隊的工作量，
    • 我們的（志願者）feedstock 維護人員將付出的時間。

這些編譯器世代可能會有也可能沒有一些供我們內部使用的非官方名稱（例如 comp7）。我們再次聲明，這些名稱的存在並不暗示對形成給定堆疊的編譯器提供任何程度的支援或穩定性。

對於不需要完全重新建置 conda-forge 的情況（即，如果新編譯器的 ABI 保持相容，直到罕見的邊角案例），我們可以僅增加全域釘選中的版本，並且它會隨著 feedstock 重新渲染而緩慢地推廣到生態系統。

對於此類 ABI 相容的升級，適用類似但較寬鬆的原則

  • 釘選同樣在全域釘選中定義，請參閱 全域釘選套件。
  • 我們不提供任何形式的特定編譯器版本長期可用性支援。
  • 當編譯器即將升級時，我們通常會以公告的形式發出通知。
  • 在不承諾任何時間表的情況下，我們在 Linux 和 OSX 上的編譯器通常非常新；在 Windows 上，我們通常使用最後一個支援的 VS 版本。

儘管缺乏明確的支援，我們仍盡力使編譯器在其各種版本中也能在 conda-forge 之外運作，甚至提供一種簡單的方法來安裝它們（透過 compilers feedstock）。

更具體地說，每個編譯器都使用一個啟動套件，該套件區分了它僅僅存在於建置環境中，以及它被預設使用的情況。當在 meta.yaml 中使用 {{ compiler('xyz') }} 時，這些套件將會被安裝，其中 'xyz' 是 'c'、'cxx'、'fortran'、'cuda'、'rust'、'go-cgo'、'go-nocgo' 之一。

我們的預設編譯器堆疊在每個平台上都非常不同；每個平台都有自己的預設編譯器，以及提供它們的 feedstock 集。由於歷史原因（編譯器與其作業系統整合的方式，以及用它們編寫的軟體數量等），影響最大的語言是 C 和 C++（儘管 Fortran 被認為是預設的一部分，尤其因為 GCC 編譯所有三種語言）。

Linux (GCC)

OSX (Clang)

Windows (MSVC)

在 Windows 上存在另一種基於 MinGW 的編譯器堆疊，它帶有 m2w64_ 前綴（例如 {{ compiler('m2w64_c') }}）。但是，由於現在大多數專案也將原生支援使用 MSVC 進行編譯，以及混合編譯器堆疊引起的一些複雜情況，它正逐漸被淘汰。

此外，有可能在 Linux 和 Windows 上使用 clang 作為編譯器

除了主要的 C/C++/Fortran 編譯器外，以下是其他編譯器的 feedstock

若要升級 Linux 或 OSX 全域釘選中預設編譯器的編譯器版本，請確保上述相關 feedstock 已針對新的主要版本重新建置，所有相關版本都同時提升，並且編譯器可以正常運作（例如，透過在某些 feedstock 上測試它們，方法是透過 feedstock 本機 conda_build_config.yaml 指定新版本）。您也應該檢查編譯器版本資訊，了解有關 ABI 不相容性的警告，並在有關升級的討論中提及任何此類通知。

對於 Windows，我們會將較舊的編譯器保留更長時間，因為使用較新的工具鏈會迫使每個想要在本地開發 conda-forge 成品的人都使用至少與其一樣新的工具鏈。您可以在這個 關於更新到 vc142 工具鏈的 issue 中找到有關此主題的更多詳細資訊。

CentOS sysroot 用於 linux-* 平台​

我們目前重新封裝來自適當 CentOS/AlmaLinux 版本的 sysroot，以與我們的編譯器一起使用。這些 sysroot 檔案可在 sysroot_linux-* 套件中取得。這些套件的版本號碼與它們封裝的 glibc 版本相符。這些版本對於 CentOS 7 為 2.17，對於 AlmaLinux 8 為 2.27，對於 AlmaLinux 9 為 2.34。

輸出驗證和 feedstock 令牌​

在撰寫本文時，anaconda.org 不支援產生 API 令牌，這些令牌的範圍設定為允許上傳某些套件但不允許其他套件。為了確保 feedstock 上傳的安全，例如，numpy feedstock 的維護人員無法推送 python 套件，我們使用套件暫存流程並發行秘密令牌，每個 feedstock 都有唯一的令牌。此流程運作方式如下。

  1. 當 feedstock 上的 CI 工作正在建置要上傳到 anaconda.org 的套件時，它會先將它們上傳到暫存通道 cf-staging。
  2. 然後，feedstock CI 工作會使用其秘密令牌和一些有關其嘗試上傳的套件的資訊，對我們的管理 webservices 伺服器進行 API 呼叫。
  3. webservices 伺服器會驗證秘密令牌、套件的完整性以及是否允許給定的 feedstock 使用該套件。
  4. 如果所有驗證都通過，則套件會被複製到 conda-forge 通道。

我們考慮兩種情況

新輸出名稱的套件驗證失敗​

新增至現有 feedstock 的新套件不會自動註冊，以防止錯字搶註和其他惡意活動。套件輸出在 feedstock 建立期間新增。如果您將套件從一個 feedstock 移動到另一個 feedstock、新增輸出套件或變更套件名稱，則需要透過 admin-requests 儲存庫 請求將新的套件名稱新增到您的 feedstock。

在極少數情況下，套件名稱可能會以明確定義的方式定期變更（例如，libllvm18、libllvm19 等）。在這種情況下，您可以使用我們的 admin-requests 儲存庫 新增符合新套件名稱模式的 glob 模式。我們使用 Python fnmatch 模組語法。符合這些模式的輸出套件將會自動為您的 feedstock 註冊。

現有輸出名稱的套件驗證失敗​

我們嘗試透過在 feedstock 中的提交/issue 上發表評論，向使用者報告此流程中的錯誤。有時這些報告會失敗。如果您認為您的上傳遇到問題，請務必檢查/嘗試以下事項

  • 確保在您的 conda-forge.yml 中設定了 conda_forge_output_validation: true。
  • 透過將空的提交推送至 feedstock，重試套件建置和上傳。
  • 在從 feedstock 分支的分支建立的拉取請求中重新渲染 feedstock 並合併。
  • 透過我們的 admin-requests 儲存庫 請求重設 feedstock 令牌。

套件建置階段和相關基礎架構​

conda-forge 中的套件幾乎1 總是透過 CI 建置。但是，當新套件首次進入 conda-forge 時，它是透過 staged-recipes 儲存庫 中的拉取請求完成的，而之後套件的每個新版本建置都在其儲存庫中建置，即所謂的 feedstock。這兩個地方使用略有不同的 CI 設定，並以相應的方式與基礎架構互動。因此，我們先描述新套件開始時的互動，然後描述現有套件在其各自 feedstock 中的互動。

首次提交至 staged-recipes​

conda-forge/staged-recipes 儲存庫使用多個基礎架構組件。

在拉取請求上

  • 套件建置管線。這些與在 feedstock 中執行的管線略有不同（它們不是由 conda-smithy 自動產生，但它們確實使用相同的底層組件）。
  • linter 由 conda-smithy recipe-lint 提供，由 @conda-forge-admin 執行。
  • 自動標籤邏輯，由 Github Actions 工作流程執行。

涉及的已驗證服務

  • Github，具有以下權限
    • 拉取請求標籤
  • Azure Pipelines

將 staged-recipes 中的新 recipe 轉換為其各自的 feedstock 發生在由 admin-requests 執行的 cron 工作中。如需更多詳細資訊，請參閱 admin-requests。作為 feedstock 建立的一部分，新的 feedstock 會收到一個 webhook，將其與 webservices 連接。

Feedstock 變更​

feedstock 可能會由於多種原因而接收變更。

推送至 main 或其他分支

  • 在 staged-recipes 中獲得批准後自動初始化提交。這些由 conda-smithy 產生，並由 admin-requests 中的自動化推送。
  • 從 admin-migrations 觸發的自動維護提交。
  • 重新渲染請求由 conda-forge/webservices-dispatch-action 的實例處理，並由 webservices 觸發。

自動拉取請求可以由以下人員開啟...

  • @conda-forge-admin，回應標題類似於 @conda-forge-admin, please... 的 issue。
  • @regro-cf-autotick-bot，處理遷移和可用的新版本。

...並由以下人員關閉

  • conda-forge/automerge-action，如果已相應標記。

在開啟的拉取請求上

  • 建置管線（更多資訊請參閱 下方）。
  • linter 由 conda-smithy recipe-lint 提供，由 @conda-forge-admin 執行。
  • 由 @conda-forge-admin 回答的 @conda-forge-admin, please... 命令評論。

在 issue 上

  • 由 @conda-forge-admin 處理的 @conda-forge-admin, please... 命令 issue。

套件建置​

建置 conda 套件的管線用於拉取請求和 main 及其他分支中的推送事件。唯一的區別是在拉取請求期間建置的套件不會上傳到暫存通道。在所有 feedstock 中維護這些最新狀態涉及多個儲存庫

  • conda-smithy 負責產生 CI 管線本身，以及支援腳本和組態檔案。這些管線和腳本可以依賴以下儲存庫中定義的程式碼和資料。
  • conda-forge-ci-setup-feedstock 提供準備和統一跨供應商的 CI 執行器所需的程式碼。它還會在成品上傳到 cf-staging 之前執行一些檢查。
  • conda-forge-pinning-feedstock 定義了許多執行時期和程式庫支援的版本，以及用於某些語言和平台的編譯器。
  • docker-images 建置 Linux 執行器的標準化容器映像。此儲存庫對 Docker Hub、Quay.io 有額外的驗證需求。

管線可以在 conda-smithy 支援的多個 CI 供應商上執行，包括

  • Azure DevOps Pipelines
  • Travis CI
  • Circle CI
  • Appveyor
  • 自行託管的 Github Actions 執行器

hook 和觸發器的註冊也由 conda-smithy 應用程式完成。

提示

conda-smithy 支援更多 CI 供應商。查看 其儲存庫 以取得更多詳細資訊。

涉及的已驗證服務

  • Anaconda.org 上傳到 cf-staging

套件驗證和發佈​

在 main （或其他分支）上建置完成後，conda 套件會上傳到名為 cf-staging 的中繼通道。從那裡，我們的 webservices（conda-forge/conda-forge-webservices）執行以下操作

  • 邏輯檢查 feedstock 令牌以驗證合法請求。
  • 邏輯檢查 cf-staging 上套件的雜湊總和，以對照 CI 中計算的值，以確保要複製的成品是相同的。
  • 邏輯檢查 feedstock 是否被允許使用 conda-forge/feedstock-outputs 儲存庫推送套件。
  • 如果所有三個檢查都通過，webservices 會將成品從 cf-staging 複製到 conda-forge。

涉及的已驗證服務

  • Anaconda.org 上傳到 conda-forge 和 cf-staging
  • conda-forge-webservices 應用程式部署本身（目前在 Heroku 上）

發佈後​

一旦上傳到 anaconda.org/conda-forge，套件不會立即提供給 CLI 用戶端。它們必須在內容傳遞網路 (CDN) 中複製。此步驟理想情況下應耗時約 15 分鐘。在某些情況下，可能會出現更長的延遲。如有疑問，請查看 conda-forge.org/status。

在 CDN 複製後，anaconda.org/conda-forge 上可用的大多數套件將不會再有任何修改。然而，在某些情況下，維護者可能需要對已發布的套件執行一些操作

  • 修補其 repodata
  • 將它們標記為損壞

Repodata 修補​

conda 套件的中繼資料最初包含在每個套件封存檔中（位於 info/ 下）。conda index 迭代已發布的 conda 套件，提取中繼資料，並將所有找到的 JSON blob 合併到一個單一 JSON 檔案中：repodata.json。這也是加入雜湊值和檔案大小的地方。這是 CLI 用戶端最初下載以解決環境的中繼資料檔案。

由於中繼資料位於套件檔案外部，因此可以修改某些詳細資訊而無需重建套件，這顯著簡化了一些維護任務。

Repodata 修補程式在 conda-forge/conda-forge-repodata-patches-feedstock 中建立，這會產生（並上傳）一個常規的 conda 套件作為結果：conda-forge-repodata-patches。這些帶有時間戳記的套件中的每一個都包含 conda-forge 上每個頻道子目錄的修補說明。Anaconda 基礎架構從這些套件中取得 JSON 檔案，並將它們應用於原始的 repodata.json 之上（原始檔案仍然可以作為 repodata_from_packages.json 下載）。

由於 conda-forge-repodata-patches-feedstock 作為常規 feedstock 進行套件發布操作，因此沒有其他基礎架構細節需要涵蓋。

將套件標記為損壞​

有時套件會以 repodata 修補程式無法修正的方式發生故障（例如，錯誤的二進制檔案）。在這些情況下，conda-forge 不會從 Anaconda.org 移除套件。相反，它會使用 broken 標籤標記它們，這具有特殊的含義：標記為此類的套件將透過自動修補程式從 repodata 中移除。此操作是可逆的，並且不會更改工件的直接 URL，工件始終可以從例如鎖定檔下載。

處理此問題的主要儲存庫是 conda-forge/admin-requests，其中包含每 15 分鐘運行的不同 Github Actions 工作流程。

對於此任務，Github Action 工作流程需要存取

  • Anaconda.org，以新增（或移除）標籤
  • Github，在成功後修改並提交輸入檔案

服務和供應商清單​

Github 資源​

除了數千個儲存庫之外，conda-forge 還使用多個其他 Github 服務。

組織​

資訊

這些組織存在，但不再積極使用

團隊​

conda-forge Github 組織擁有數千個團隊。它們大多數與 feedstock 相關聯，但有一些特殊的團隊不是！

組態​

Bot 帳戶​

資訊

這些帳戶存在，但不再積極使用

應用程式​

  • conda-forge-curator
  • conda-forge-webservices
資訊

這些應用程式存在，但不再積極使用

  • conda-forge drone 實例

工作流程​

持續整合​

另請參閱

請參閱 conda-forge.yml 文件，以了解如何組態您的 CI 提供者。

Azure Pipelines​

conda-forge 受益於 Microsoft 慷慨提供的託管執行器。

Travis CI​

Cirun​

  • 🌐 https://cirun.io
  • 📍 僅在選定的 feedstock 上可用
  • 🛠 提供多種架構（取決於 feedstock 組態）
  • 🔒 需要存取 Anaconda.org (cf-staging) 和已組態的後端

使用 @conda-forge-daemon 進行組態。

組織範圍的組態可以在 .cirun 儲存庫中找到。

資訊

這允許例如存取選定 feedstock 的 GPU 啟用執行器，如 https://github.com/Quansight/open-gpu-server 中所述。

Github Actions​

已停用的服務​

交付和發布​

Anaconda.org​

Docker Hub​

Github Packages​

Github Releases​

Quay​

伺服器​

Heroku​

其他服務​

腳註​

  1. 極少數套件由於特殊的資源需求而無法透過 CI 建置。這些套件可以按照 CFEP-3 中規定的規則手動建置和上傳。↩