跳到主要內容

基礎設施

本頁面概觀 conda-forge 基礎架構，亦即 conda-forge 貢獻者及第三方供應商所維護之各種區塊的帳戶，共同形成 conda-forge 作業基礎。

我們先從 conda-forge 自行維護的不同 Github 儲存庫 開始，再說明可在這些儲存庫中使用的管理命令（所謂的 管理網路服務），接著是 CI 服務，也就是用於建置與維護軟體套件的第三方供應商。接著，我們說明 編譯器和執行環境 中軟體套件特定面向的建置環境，以及 上傳至套件伺服器 的詳細資訊。

然後，我們將了解建置軟體套件的流程如何與架構的不同部分互動。

我們以 所涉實體的簡要清單 作為結尾。

儲存庫 ​

分階段配方 ​

此儲存庫是 conda-forge 的入口，使用者可以在此提交新的配方，一旦經過審核和接受，將產生新的原料和團隊。您可以在 分階段處理 中找到提交新封裝配方的詳細指南。

分階段配方剖析 ​

recipes/ 包含一個或多個有使用者提交配方的 子目錄。大多數情況下，一次只會提交一個配方，但如果出現多個子目錄，則 build_all.py 腳本將以正確的順序建立它們，以便滿足相依性。

.ci_support 包含 conda-build YAML 設定檔，但在此情況下（如果與原料比較），您還會發現一些腳本

  • build_all.py：以正確（以拓樸方式排序）的順序呼叫 conda-build。
  • compute_build_graph.py：透過提供所有已提交配方的工作圖表來支援 build_all.py。

包含在 .ci_support 中的 YAML 檔是最低限度的，而且與您在原料中找到的檔案不同。相反地，conda-build 會在執行時取得這些檔案並將它們與來自 conda-forge-pinning 的固定結合。另外請注意，staged-recipes 僅為 x64 建立。對於其他架構的支援只能在提供原料後進行。

  • Linux：linux64.yaml 加上 CUDA 變體 (10.2、11.0、11.1 和 11.2)。
  • macOS：osx64.yaml。
  • Windowswin64.yaml。

.scripts 目錄包含與原料中會用於持續整合管線的 shell 腳本大致相同的腳本。但是，由於 staged-recipes 不支援重新渲染，因此這些腳本是手動同步的，而且很常見會看到一些差異。

工作流程 ​

staged-recipes 上執行的主要工作是 conda-build 工作，它會執行在每個公關 (並推播至 main) 上，以檢查配方是否正確地建立套件。這些工作會在 .azure-pipelines/ 中定義的 Azure Pipelines 上執行。

原料的實際建立是在 conda-forge/admin-requests 中執行的。

其他工作流程有助於使用者正確設定他們的配方。它們會對公關中的事件做出反應

外部服務也連線至 staged-recipes

  • @conda-forge-admin 機器人 (部署在 webservices) 將根據配方的內容對 PR 進行程式碼檢查並提供提示。

原料素材​

  • ⚙️ 部署在 Github 存放庫
  • 🔒 可存取 Azure Pipelines、Github Actions、Anaconda.org (cf-staging)
  • 🔐 可能可透過 admin-requests (待完成工作) 存取 Travis CI、Cirun
  • 🤖 與 admin-migrations、admin-requests、autotick-bot 和 webservices 整合。

Conda-forge 擁有數千個原料素材。每個原料素材都存放一個配方，以及所需的管線、支援腳本和設定檔資訊。

原料素材的內容有明確說明。只有兩個位置是由使用者管理的

  • recipe/：包含 conda-build 指令，用來建置套件。它至少需要一個 meta.yaml 檔案，而且通常也會將選用的 conda_build_config.yaml 放置在這裡。
  • conda-forge.yml：這是原料素材設定檔。
警告

切勿手動編輯未列於上述的檔案！變更會在下次原料素材重新呈示時被覆寫。

將這兩個來源與一些外部元件結合後，conda-smithy 將產生 (呈示) 原料素材的內容。許多目錄之所以會這樣命名，是因為這是外部服務 (如 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 管線中執行的操作。
更多資訊（進行中）
  • 重新渲染饋送資料
  • 建議工作流程

饋送資料單一存放庫​

一個包含所有饋送資料的存放庫，其中包含子模組。

饋送資料輸出​

此存放庫是饋送資料名稱與其產出的套件（人工製品）的註冊機制。

其主要目的是提供允許清單供驗證伺服器使用，以防止惡意跨饋送資料建構，儘管它也是在網站 套件區段 中所公開的 饋送資料 <-> 套件 資訊地圖。

cdt 建構​

此特殊存放庫為 conda-forge 建構核心相依資料樹套件（僅限 Linux）。它不使用饋送資料自動機器。取而代之的是，它有自己的 Azure 管線工作流程和詳盡的 README。

msys2 配方​

這是 Anaconda 中舊社群配方存放庫的分支，其中包含 msys2 配方，位於 msys2/ 目錄下。還要留意 common-scripts/ 資料夾中的支援程式碼。

網站​

目前的 conda-forge.org 是靜態產生網站，發佈至 Github Pages。

文件由 Docusaurus 建立，原始檔案位於存放庫中 docs/ 目錄。

如果您發現任何錯字、錯誤、不清楚的說明或可以涵蓋的新主題，您可以針對文件提出變更建議。更多詳細資訊，請參考 改善文件。

除了靜態文件，網站還提供 conda-forge 目前狀態的資訊，以及套件對應到原料的對應表。

元資料存放庫​

這些存放庫主要包含 conda-forge 生態系統中其他部分使用的元資料。

conda-forge 固定​

主機 conda-forge 的全球固定，以及進行中的遷移。

套件範圍的相依性固定定義於 conda_build_config.yaml 中的 conda-forge/conda-forge-pinning-feedstock。

更多 conda-forge 範圍的套件固定的資訊，請參考 全域固定套件。

如果您認為需要進階 pin，請開啟一個 PR 和/或一個問題，有關更新全球 pin 套件的更多資訊，請參閱 更新套件 pin。

conda-forge-repodata-patches​

此儲存庫會建立 repodata.json 修正檔，由 Anaconda.org 用來修正已發佈套件中的元資料。

conda-forge-ci-setup​

此特殊原料套件提供一個套件，來定義安裝和設定跨供應商的常見 CI 設定的邏輯。

regro/cf-graph-countyfair​

這是 autotick-bot 使用的圖形資料。

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

docker-images​

此儲存庫會建立 Docker 映像，用於在所有 Linux 建置中提供一個統一的系統。

程式碼儲存庫​

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

Smithy​

這是用於產生和維護主要原料的工具。

大部分用途都已自動化到我們的基礎架構中

  • 原料產生和服務註冊於 staged-recipes
  • 由conda-forge-admin於webservices完成公關的重新產生（重新渲染）、程式碼檢查和暗示

不過，你也可以在你的鍛造部署中或本地使用它。對於本機偵錯，以下命令會很有用

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

Smithy 包含了 conda-forge 的維護程式碼，這會由conda-smithy指令列工具和 管理員網路服務使用。

conda-forge/conda-smithy 是回報以下項目問題的正確儲存庫

  • 重新渲染處理程序
  • 配方程式碼檢查程式
  • CI支援公用程式

conda-smithy還包含你應該用於重新渲染指令列手動重新渲染的指令列工具（請參閱 重新渲染原料）。

Smithy 可以用於非 conda-forge 目的。舉例來說，可用於設定非 conda-forge 基礎架構的自建置 Azure 代理程式。（你也可以考慮使用 Azure 虛擬機器縮放組代理程式，執行起來可能比永久啟用的代理程式便宜。）

網路服務​

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

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

regro/cf-scripts​

autotick-bot 的程式碼和邏輯。

自動維護​

這些元件會在自動化方式下執行動作，由特定事件或作為迴圈的一部分連續觸發。

admin-migrations​

此儲存庫會主辦於 24/7 執行中的工作流程。它的工作就是處理自動化迴圈，其中會加入一些維護工作。它的主要使用者是核心團隊。

admin-requests​

此儲存庫會主辦在使用者發起動作觸發時執行的工作流程。這通常會透過一個 PR 來完成，在 PR 獲得核准、合併後會觸發要求的動作（標記套件為錯誤、封存 feedstock 等）。

它也會替在 conda-forge/staged-recipes 中合併的配方的 feedstock 建立新的 feedstock。 create_feedstocks 工作流程 會每小時執行數次，在 conda-forge 組織中建立新的 feedstock 儲存庫。核心邏輯定義在 Python 腳本 .github/workflows/scripts/create_feedstocks.py 中。

autotick-bot​

備註

較舊的儲存庫 regro/autotick-bot 已經不再使用；此機器人目前直接執行於 regro/cf-scripts 中。

網路服務​

這個網路應用程式提供多種服務，如

  • @conda-forge-admin機器人和它@conda-forge-admin，拜託 ...命令
  • 將cf-staging驗證至conda-forge（同時複製）
  • 狀態監控

管理員網路服務​

conda-forge 在 Heroku 中執行一個稱為 conda-forge-webservices 的網路服務。

下列服務會在基礎材料上預設執行

  • 它會逐行檢查程式碼中的 PR，並回報程式碼是否處於良好狀態。
  • 當維護者被新增至程式碼時，每一個維護者都會被新增至團隊，並授予推播基礎材料的權限。

網路服務也會接收問題和程式碼評論，讓你可以要求執行下列服務

@conda-forge-admin，拜託，重新渲染​

在基礎材料的程式碼評論中輸入上述字句，會重新渲染基礎材料，並將變更推播至你的程式碼評論中。請務必勾選 PR 右側欄位最下方的「允許維護者編輯」按鈕。如果你在問題的評論中輸入此字句，機器人會建立一個新的プル請求，並完成要求的重新渲染。

請 @conda-forge-admin 新增 noarch：python​

於供料需求的公關或問題中輸入上述片語，將在建構中新增 noarch：python 並幫您重新放送供料需求。

請 @conda-forge-admin 更新程式碼檢查​

於供料需求的公關中輸入上述片語，將再次檢查公關的程式碼。

請 @conda-forge-admin 新增團隊​

於問題中輸入上述片語，將為供料需求更新團隊。這通常是自動進行的。

請 @conda-forge-admin 重新啟動 CI​

於供料需求或分階段食譜的公關中輸入此指令，將關閉公關，然後再開啟公關，導致所有 CI 建構重新啟動。

請 @conda-forge-admin 呼叫團隊​

於供料需求或分階段食譜的公關中輸入此指令，將使管理員機器人 @ 標記與儲存庫相關聯的團隊。此指令對尚未成為 conda-forge 成員，因此無法 @ 標記 staged-recipes 團隊進行公關審查的人員很有幫助。

請 @conda-forge-admin 呼叫 conda-forge/​

於供料需求或分階段食譜的公關中輸入此指令，將使管理員機器人 @ 標記個別團隊。此指令對尚未成為 conda-forge 成員，因此無法 @ 標記其他人（因 GitHub 的一般限制）的人員很有幫助。

請 @conda-forge-admin 重新執行機器人​

於公關留言中輸入此指令，將在該公關中新增 bot-rerun 標籤。此標籤將導致發佈遷移和版本更新的 auto-tick 機器人關閉目前的公關並重新發佈它。將此標籤新增至非機器人發佈的公關中不會有任何影響。

請 @conda-forge-admin 新增機器人自動合併​

在 Issue 的標題或留言中輸入此指令會指示管理員機器人在 auto-tick 機器人開啟通過的 PR 之自動合併服務的 PR。此功能目前為試驗性功能。更多詳細資料，請參閱此處。對於任何回饋、錯誤和/或問題，請在對 regro/cf-scripts 開啟 Issue 問題！

@conda-forge-admin，請移除機器人自動合併​

在 Issue 的標題或留言中輸入此指令會指示管理員機器人在停用 automerge 的情況下開啟 PR，復原 請新增機器人自動合併 指令。

@conda-forge-admin，請新增使用者 @username​

在飼糧的 Issue 標題中輸入上述字句會製作加入特定使用者至飼糧的 PR。core 的維護者或成員便可合併此 PR 來加入使用者。請勿修改此 PR 或調整提交訊息。此 PR 被設計為跳過建立套件。

@conda-forge-admin，請更新版本​

在飼糧的 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 的套件。合併聯合儲存庫提出要求後，可能需要在 TravisCI 執行同步你的儲存庫才能看到重新載入和取消按鈕。請前往 https://app.travis-ci.com/account/repositories 按下「同步帳戶」按鈕。

啟用 Travis​

TravisCI 應該僅用於在原生 Linux aarch64 和 ppc64le 上組建配方。

將下列項目中的對應行新增至 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 上組建。

自動合併​

自動合併服務使用此 儲存庫 中的 GitHub 動作。此動作在 prod 標籤上的 Docker 容器 中執行。請參閱儲存庫 README.md 以取得更多詳情。若符合下列兩個條件集中的任一個，公開關係會自動合併

  1. 來自 regro-cf-autotick-bot，標題中包含 [bot-automerge]、所有狀態都已通過，而且 feedstock 允許自動合併
  2. 已加上 automerge 標籤，而且所有狀態都已通過。

對於來自 regro-cf-autotick-bot 的公開關係，如果你要編輯公開關係，可將 [bot-automerge] 標籤從公開關係標題中移除。

重新呈示​

重新渲染服務是由 Heroku 應用觸發。它使用這個 儲存庫 中的 GitHub 動作。此動作在 prod 標籤的 Docker 容器 中運作。詳情請參閱儲存庫 README.md。

跳過 CI 建置​

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

相關連結

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

由於在開源社群中的地位，conda-forge 提升了特定 CI 服務的存取能力。這是社群資源，委託給 conda-forge 用於建置套件。因此，我們無法在任何 CI 服務的原料中支援第三方或「標籤外」的 CI 作業。如果我們發現此類使用，我們會禮貌地要求維護人員更正情況。如果情況無法更正，我們可能會採取更嚴肅的行動，包括封存原料或將維護人員從組織中移除。

編譯器和執行環境​

conda-forge 建置和維護自己的一組編譯器，供各種語言和/或系統使用（例如，C、FORTRAN、C++、CUDA 等）。這些編譯器用於我們所有的 CI 建置，以建置 conda-forge 發布的所有工件。

這個編譯器基礎架構除了建立一切，還有一個重要的角色，就是確保套件之間保持相容性。這是因為已編譯的套件有一個所謂的 應用程式二進制介面 (ABI)，而且編譯器基礎架構的變更可能會破壞這個 ABI，導致當機、誤算等問題。一般來說，使用一致的編譯器版本可以大幅降低 ABI 破壞的風險。

編譯器一般都會盡力在不同版本之間維持 ABI 相容性，這表示將針對相同目標產生的不同版本的相同編譯器所產生的成品組合起來，不會出現問題。由於 ABI 的特性（也就是軟體和硬體之間龐大的介面，有數不清的邊界案例），有時候跨編譯器版本會產生針對特定面向的非預期變更，然而這在實際應用上並未導致廣泛的問題。

相反地，當編譯器有意變更 ABI（像是 MSVC 在 vc14 系列之前的每個版本所做的），每個已編譯的套件都需要針對那個新 ABI 重新建置，而且無法與舊 ABI 的建置混合。雖然現在比較不常見，但理論上編譯器堆疊中的重大基礎架構大修也有可能強制進行完整重新建置。

如此大規模的變更——需要重新建置 +/- conda-forge 全部的內容——需要非常多的工夫，但值得慶幸的是，近年來並不需要進行這種程度的全部重新建置，而且我們也成功進行較不具破壞性的編譯器升級。

不過，大規模的 ABI 破壞仍然有可能（例如 MSVC 正在規劃在 vc14 之後推出 vNext），因此我們針對這種情況維持我們的政策。儘管我們沒有針對一代 ABI 相容編譯器做出任何正式的支援承諾，但歷來我們都根據下列（非約束性的）原則予以維護。

  • 各種語言和平台的目前編譯器和版本的正式來源，是 conda_build_config.yaml，位於 conda-forge/conda-forge-pinning-feedstock 中，說明載於 全局固定套件 中。
  • 我們對於特定編譯器世代的長期穩定性和支援，不會提供任何形式的支援。
  • 我們會不定期地在非正規的方式升級編譯器，具體時間會依我們有多少時間和精力而定。注意，由於我們強制執行執行時期約束，因此這些編譯器升級並不會破壞現有的套件。不過，如果您在 conda 外部使用編譯器，可能會發生問題。
  • 當 ABI 非相容的編譯器變更即將發生時，我們通常會以公告的形式提供通知。注意這些變更需要一點時間才能完成，所以您通常會有時間在需要的時候做好準備。
  • 我們在考量編譯器遷移時會想到的某些準則，包括
    • 對生態系統的破壞程度，
    • 核心團隊的工時
    • 我們志工原物料維護者的時間成本

這些編譯器版本可能有或沒有供我們內部使用的一些非官方名稱（例如：comp7）。我們再次提醒，這些名稱是否存在並不表示我們提供任何程度的支援或穩定性給組成給定函數庫的編譯器。

對於不需要完全重建 conda-forge 的情況（也就是說，如果新編譯器的 ABI 仍然相容，但有少數特殊情況），我們只要在我們的全域固定版本中增加版本，而隨著原物料重新繪製，它將慢慢推展到生態系統中。

對於這些 ABI 相容的升級，也適用相似的原則，但較寬鬆

  • 固定版本也在全域固定版本中以相似的形式定義，請參閱 全域固定版本套件。
  • 我們不提供任何種類的支援，例如給定編譯器版本能長期使用保證。
  • 當編譯器將進行升級時，我們通常會透過公告形式提供通知。
  • 我們沒有承諾任何時程，在 Linux 和 OSX 上的編譯器通常都是最新的版本；在 Windows 上，我們通常使用最後一個受支援的 VS 版本。

儘管沒有明確的支援，我們還是會嘗試讓編譯器在 conda-forge 外也能使用其各種版本，甚至提供一個簡單的方式來安裝它們（透過 編譯器原物料）。

更具體來說，每個編譯器使用一個啟動套件，其中區別在於它只是單純出現在建置環境中或是預設使用。在 meta.yaml 中使用 {{ compiler('xyz') }} 時，會安裝它們，其中 'xyz' 可能是 'c', 'cxx', 'fortran', 'cuda', 'rust', 'go-cgo', 'go-nocgo' 之一。

我們的預設編譯器函數庫在每個平台上組成的完全不同；每個平台都有自己的預設編譯器和自己的一組提供它們的原物料。由於歷史原因（編譯器與它們的操作系統整合的方式，以及以它們編寫的軟體數量等），影響最重大的語言是 C 和 C++（儘管 Fortran 被視為預設的一部分，部分原因是因為 GCC 編譯所有三者）。

Linux (GCC)

OSX (Clang)

Windows (MSVC)

Windows 上存在一個基於 MinGW 的替代編譯器堆疊，它可以使用 m2w64_ 詞首（例如 {{ compiler('m2w64_c') }}）。然而，由於大多數專案現在本機支援 MSVC 編譯，加上混合編譯器堆疊產生的數個複雜問題，因此它現在已不再使用。

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

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

若要升級 Linux 或 OSX 全域固定中的預設編譯器版本，請確保上述各個饋入程式已針對新主要版本重新建置，所有相關版本同時解除，且明顯地，編譯器能夠運作（例如透過指定饋入程式本機中 conda_build_config.yaml 中新版本，在部分饋入程式上對它們進行測試）。你也應該查看編譯器發行說明以了解 ABI 不相容性的警告，並在升級討論中提及任何此類通知。

對於 Windows，我們會持續使用舊編譯器較長時間，因為採用較新的工具鏈會強迫所有想要在 conda-forge 手工製品上進行在地開發的使用者，使用至少跟最新相同的新工具鏈。你可以在此 關於更新至 vc142 工具鏈的問題 中找到更多關於此主題的詳細資訊。

針對 linux-* 平台的 CentOS sysroot​

我們目前會重新封裝適用於編譯器的 CentOS 適當版本中的 sysroot。這些 sysroot 檔案可以在 sysroot_linux-* 套件中取得。這些套件的版本號碼與它們封裝的 glibc 版本相符。這些版本對於 CentOS 6 而言為 2.12， CentOS 7 而言為 2.17。

對於 ppc64le 上的 gcc/gxx/gfortran 版本在 8.4.0 之前，以及 aarch64/x86_64 上的 7.5.0 之前，我們已經建置自己的 glibc 版本。此做法現在已棄用，改為使用基於 CentOS 的 sysroot。此外，自上列相同編譯器版本開始，我們已移除 sysroot 路徑中的 cos* 部分。新的 sysroot 路徑中只包含 conda，而非 conda_cos6 或 conda_cos7。

輸出驗證和饋入程式代碼​

在撰寫本文時，anaconda.org 不支援產生 API 代碼用於允許部分套件上傳，但不支援其他套件上傳。為保護饋入程式上傳，因此例如 numpy 饋入程式的維護人員無法推入 python 套件，我們會運用套件存放程序，並針對每個饋入程式發出個別的祕密代碼。此程序的運作方式如下。

  1. 當饋入程式上的 CI 工作正在將套件建置為上傳至 anaconda.org 時，它會先將套件上傳至存放頻道「cf-staging」。
  2. 接著，饋入程式 CI 工作會使用其祕密代碼和它正嘗試上傳的套件的一些資訊，對我們的管理 web 服務伺服器進行 API 呼叫。
  3. web 服務伺服器會驗證祕密代碼、套件的完整性，以及是否允許將套件用於既定的饋入程式。
  4. 如果所有驗證都通過，套件會複製至 conda-forge 頻道。

我們嘗試透過提交/問題動態中的註解，向使用者報告此流程中的錯誤。但請注意，有時這些會失敗。如果您認為上傳遇到問題，請確保在您自己的 conda-forge.yml 中設定 conda_forge_output_validation: true，並使用最新版的 conda-smithy 重新產生您的原料。最後，新增到原料的新套件會自動註冊，一旦上傳成功，就沒有其他原料可以上傳同名套件。

但有時，可能因套件重新命名或重新結構化等原因，需要從另一個原料產生套件比較有道理。這種情況下，您可能需要將新原料加入 套件輸出 對應中。如果沒有這麼做，輸出驗證流程會依設計阻止從新原料上傳套件。如果已正確執行此步驟且已上傳套件，您再向 conda-forge 核心開發人員要求封存舊原料即可。

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

conda-forge 中的套件大多1 都是透過持續整合來建置。但當一個新套件第一次進入 conda-forge 時，會透過 staged-recipes 儲存庫 中的拉取要求來進行，之後每次新建置時，則是在套件儲存庫（也就是原料）中建置。這兩個地方使用的持續整合設定略有不同，且會與基礎架構相應互動。因此，我們會先說明新套件的互動方式，再說明現有套件在其各自的原料中的互動方式。

最初提交至 staged-recipes​

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

於拉取要求中

  • 套件建置流程。這些與原料中執行的略有不同（它們不會自動由 conda-smithy 產生，但仍使用相同的基本元件）。
  • Linter 由 conda-smithy recipe-lint 提供，由 @conda-forge-admin 執行。
  • 自動標籤邏輯，由 Github Actions 工作流程執行。

相關的驗證服務

  • Github，有以下權限
    • 公關標籤
  • Azure Pipelines

將 staged-recipes 中的新配方轉換為各自的原料是在 admin-requests 執行的 cron 工作中執行。更多詳細資訊，請參閱 admin-requests。在原料建立的過程中，新原料會收到一個 webhook，將它與 網路服務 相連。

原料變更​

原料會因各種原因而收到變更。

推入至main或其他分支

  • 程式會在通過staged-recipes核准後，自動建置提交。這些都是由conda-smithy產生並由admin-requests中的自動化推入。
  • 從admin-migrations觸發的自動維護提交。
  • 重新呈現的請求是由conda-forge/webservices-dispatch-action實例處理並由Web 服務觸發。

自動化プル要求可以開啟...

  • @conda-forge-admin，回應某些標題為@conda-forge-admin, please...之議題。
  • @regro-cf-autotick-bot，處理可用之遷移和新版本。

...並關閉

  • conda-forge/automerge-action，如果適當標籤。

開啟プル要求

  • 建置管線 (更多在下面)。
  • Linter 由 conda-smithy recipe-lint 提供，由 @conda-forge-admin 執行。
  • @conda-forge-admin, please...命令註解，由@conda-forge-admin回答。

議題

  • @conda-forge-admin, please...命令議題，由@conda-forge-admin處理。

套件建置​

建置 conda 套件之管線用於プル要求和推入活動在main和其它分支。唯一不同是建立在プル要求期間的套件不會上傳到分段頻道。要讓它們在所有原料中保持最新，涉及多個儲存庫

  • 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 管線
  • Travis CI
  • Circle CI
  • Appveyor
  • 自行架設 Github 動作執行程式

掛勾和觸發器註冊也是由conda-smithy應用程式完成。

提示

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

相關的驗證服務

  • Anaconda.org 上載至 cf-staging

軟體套件驗證與發布​

經由 main（或其他分支）建置後，conda 軟體套件上載至名為 cf-staging 的中間管道。之後，我們的網際網路服務 (conda-forge/conda-forge-webservices) 會執行下列動作

  • 邏輯檢查 feedstock token 驗證要求的合法性。
  • 邏輯檢查 cf-staging 上的軟體套件雜湊總和與 CI 中計算的值，以確保要複製的成品相同。
  • 邏輯檢查 feedstock 獲准使用 conda-forge/feedstock-outputs 儲存庫推送軟體套件。
  • 如果這三個檢查全部通過，網際網路服務會將成品從 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 作為一個常規原料供應站操作套件發佈，因此沒有其他要涵蓋的基礎架構詳細資料。

將一個套件標示為已中斷​

有時一個套件會出現 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 組織有數千個團隊。其中大多數與原料相關，但有少數幾個特別的團隊不屬於此類！

設定檔​

機器人帳號​

資訊

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

應用程式​

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

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

  • conda-forge drone instance

工作流程​

持續整合​

另請參閱

參閱 conda-forge.yml 文件，以了解如何設定 CI 供應商。

Azure Pipelines​

Conda-forge 受益於 Microsoft 主控提供的執行程式。

Travis CI​

Cirun​

  • 🌐 https://cirun.io
  • 📍 僅適用於選定的原料庫存
  • 🛠 提供若干架構（取決於原料庫存設定）
  • 🔒 需要存取 Anaconda.org (cf-staging) 和已設定的後端

與 @conda-forge-daemon 設定。

可以在 .cirun 存放庫 中找到全組織設定。

資訊

例如，這允許存取已選定原料庫存的 GPU 已啟用執行程式，如 https://github.com/Quansight/open-gpu-server 所述。

Github Actions​

已取消的服務​

發布和配送​

Anaconda.org​

Docker Hub​

Github 套件​

Github 版本​

Quay​

伺服器​

Heroku​

其他服務​

註腳​

  1. 由於特殊資源需求，極少數套件無法透過 CI 建構。根據 CFEP-3 中制定的規則，可以手動建構並上傳這些套件。↩