Feedstock

Feedstock 是一個 recipe 的家；在多輸出 recipe 的情況下，它可能會產生多個 conda 成品。Feedstock 是 recipe 生命週期中大多數事件發生的地方。

初始化

Feedstock 儲存庫是在 staged-recipes 中合併後建立的（請參閱Feedstock 建立以了解該過程的詳細資訊）。

套件建置圖

套件建置可以由幾個事件觸發，這些事件在下一節中描述。在所有這些情況下，都會發生以下順序。

注意

1. 對於 Linux 和 noarch 套件，建置本身是在 CI 上的 Docker 容器中進行的。在 macOS 和 Windows 上，CI 執行器系統映像會在稍微調整後使用。
2. 本機驗證在 CI 上進行，並透過查詢feedstock-outputs 儲存庫來檢查建置期間產生的成品是否允許用於此 feedstock。
3. 伺服器端驗證基本上與 2 相同。它在發布基礎設施內部重複進行，以防止在 feedstock 層級發生潛在的有意或無意干擾，因為 feedstock 層級更容易存取。
4. 僅當本機驗證 (2.) 成功時才會觸發上傳。此外，它僅在特定條件下執行，例如在 main 中的 commit，但不在 PR 中。請注意，如果伺服器端驗證 (3.) 失敗，套件也可能無法從 cf-staging 傳輸到 conda-forge。如果 2. 成功而 3. 失敗，這通常是由於過期的 token。

觸發新建置的事件

套件建置要么作為 PR 的一部分觸發，要么在 feedstock 儲存庫中分支的 commit 上觸發（這通常源自 PR 的合併）。

警告

feedstock 中任何分支上的任何 commit 都可能導致套件的建置和發布。為了避免隨意發布不當的套件，開發分支絕對不能新增到 feedstock 儲存庫。相反地，它們存在於 feedstock 儲存庫的 fork 中，相關的工作僅透過 pull request 新增。

幾乎所有對 feedstock 儲存庫的變更都是透過 PR 執行的。手動維護者介入和 conda-forge 自動化都是如此。

資訊

可以將 commit 直接新增到分支。這偶爾用於使用空的 commit 重新觸發失敗的 CI 執行

git commit --allow-empty -m "Retrigger CI"

手動提交的 PR

這些 PR 不是自動化的。任何 Github 使用者都可以透過 fork feedstock、從 main 建立新的分支並新增必要的 commit 以實現預期的變更（例如，建置新版本或新增新的平台）來開啟新的 PR。

PR 的審查、批准和合併，或拒絕和關閉 PR，由 feedstock 維護者和/或 conda-forge/core 團隊決定。

在 PR 的生命週期中，將會發生一些自動化操作

• linter 將掃描 recipe 的狀態，以要求變更並提出改進建議。如果未滿足，這將導致 CI 執行失敗。linter 失敗絕對不能在沒有明確的核心批准的情況下被忽略。
• PR 範本會要求您每個 PR 至少重新渲染 feedstock 一次。除其他事項外，這將確保 CI 配置是最新的。您可以使用 bot 命令 @conda-forge-admin, please rerender 在任何評論中，或透過 conda-smithy rerender 在本機執行。

自動化 PR

在許多情況下，conda-forge 自動化將建立 PR。在這些情況下，審查和合併 PR，從而在儲存庫上觸發操作，通常是 feedstock 維護者的特權。

分支上的每個 commit 都會觸發 ci，除非其 commit 訊息包含標籤 [ci skip]，這可以透過將其包含在 PR 標題中來為 PR 實現。某些提供者在 PR 期間會忽略此標籤，但在由像 main 這樣的分支觸發的執行中會遵守它。

版本更新

當上游發布新版本時，需要建立一個 PR，以執行對 feedstock 的必要更新。至少，這包括更新上游來源成品的版本、下載 URL 和雜湊值。此外，可能還需要對 recipe 進行其他變更，例如更新的相依性需求、套件的 noarch 狀態的變更，或建置或測試腳本的調整。雖然這些最後的變更通常需要由維護者完成，但 conda-forge 具有複雜的功能來新增初始版本更新 PR。

它是如何運作的？

這在 cf-scripts 的 CI 中分兩個步驟進行。

首先，版本資訊會從上游來源更新，並儲存在 cf-graph-countyfair repo 中，更具體地說是在 versions 目錄樹中，依雜湊值巢狀排列，每個套件一個檔案。

其次，主要的 bot CI 工作，cf-scripts 中的 bot-bot 動作會為所有在上游有新版本的套件建立 PR。以下是執行方式的簡化圖表。如需完整圖片，請閱讀下方。

提交後，由 feedstock 維護者檢查 PR、進行任何必要的調整並將其合併到 feedstock 分支中。

此版本更新是 migrator 的一個範例。在以下章節中閱讀有關 migrator 的更多資訊。

migrator 的重建

版本更新是 migrator 的一個範例。實際上，有更多場合和原因需要更新 recipe，例如，重新編譯其他未變更的二進位程式或程式庫以連結到較新版本的相依性，或新增對新架構的支援。這種用例由 migrator 處理，migrator 是一種通用的 recipe 重寫工具。

auto-tick 的更完整圖片如下

Migrator 是一種強大的機制，幾乎可以執行任意 recipe 變更。它們是用 Python 編寫的，目前的 migrator 集合可以在 regro/cf-scripts 儲存庫中找到。