R 4.0 遷移回顧

雖然 R 4.0 的遷移在功能上已完成相當長一段時間，但最近 r-java 及其相依套件的遷移，正好提供了一個很好的機會來撰寫關於 conda-forge 中大規模遷移的技術問題，以及我們如何解決這些問題的回顧。

R 4.0 的遷移重建了 conda-forge 中每個以 r-base 作為需求的套件，包括超過 2200 個 feedstock。 conda-forge 中如此大規模的遷移面臨幾個障礙。首先，由於每個 feedstock 都是一個獨立的 GitHub 儲存庫，因此需要合併超過 2200 個提取請求 (PR)。其次，conda-forge 在 anaconda.org 上的套件位於 CDN（內容傳遞網路）之後。這項服務降低了 Anaconda Inc. 的網路託管成本，但也造成了大約 30 分鐘的延遲，從套件上傳到 anaconda.org 到它透過命令列使用 conda 顯示為可用之間。因此，即使套件的相依性已經建置完成，我們也必須等到它們出現在 CDN 上，才能成功發出下一個 PR 並使其正確建置。最後，現有的機器人和 conda 基礎設施限制了遷移的吞吐量，部分原因是 conda 求解器的速度。

鑑於 R 4.0 遷移的規模，我們藉此機會嘗試了一系列新技術來加速大規模遷移。主要的增強功能包括使用 GitHub Actions 自動合併 PR、使用 mamba 快速檢查套件環境的可解性，以及為 autotick 機器人啟用長時間運行的遷移任務。總而言之，R 4.0 的大部分 feedstock 在不到一週的時間內被重建，許多 PR 從發出到合併的時間在 30 分鐘或更短的時間內完成。這些對 autotick 機器人和 conda-forge 基礎設施的增強功能，可用於增強未來的遷移（例如，Python 3.9）並減少 feedstock 的維護負擔。

自動合併 conda-forge PR

在 conda-forge 上的典型遷移中，我們會向 feedstock 發出 PR，然後要求 feedstock 維護者確保其通過並合併它。在 R 4.0 遷移的情況下，conda-forge 上 R 套件的維護者在絕大多數 feedstock 上使用維護團隊（即 @conda-forge/r）。這個團隊很小，因此手動合併 2000 多個 PR 是一項龐大的工程。因此，在他們的許可下，我們將 conda-forge 自動合併功能添加到他們維護的所有 R feedstock 中。自動合併機器人依賴 GitHub Actions，能夠自動合併來自 autotick 機器人的任何 PR，這些 PR 通過了配方 linter、持續整合服務，並且在 PR 標題中具有特殊的 [bot automerge] slug。此功能消除了等待維護者合併 PR 的瓶頸，並減輕了 R 維護團隊的維護負擔。

使用 mamba 檢查可解性

雖然能夠自動合併 PR 消除了執行 R 4.0 遷移的大部分工作，但它依賴於 PR 在第一次發出時正確建置。由於 CDN 延遲和套件相依性的建置時間，套件的相依性可能在它們的所有遷移 PR 合併後不會立即可用。如果機器人在相依套件可用之前發出套件遷移 PR，則 PR 將因環境無法解決而失敗，並且必須手動重新啟動。這種失敗將抵消首先使用自動合併的任何好處。

為了控制這種邊緣情況，我們採用了 mamba 套件，在發出 PR 之前檢查 PR 環境的可解性。 mamba 是 conda 的快速替代方案，它可以更快地產生環境解決方案，速度快幾個數量級。由於我們必須多次執行 PR 環境檢查，因此極快的求解器對於使程式碼效率足以作為 autotick 機器人的一部分運行至關重要。我們最終使用 mamba 來嘗試安裝要遷移的 feedstock 產生的每個變體的相依性。透過此檢查，autotick 機器人能夠發出第一次嘗試就通過的遷移 PR，因此可以自動合併，許多在 30 分鐘或更短的時間內完成。

提高 Autotick 機器人的效率

最後，我們對 autotick 機器人基礎設施進行了幾項升級，以提高機器人的正常運行時間和效率。首先，我們從每小時的 cron job 遷移到一組鏈式 CI job。此變更消除了機器人運行之間的停機時間。其次，我們開始將 autotick 機器人從一個龐大的程式碼塊重構為一組分散的微服務，這些微服務並行執行各種獨立任務。這些獨立任務用於檢查先前發出的 PR 的狀態等，它們是分開運行的，使機器人可以花更多時間發出 PR。最後，我們最佳化了 PR 的內部優先順序，以確保機器人將更多時間花在較大的遷移上，因為那裡有更多工作要做。對 autotick 機器人基礎設施的更多工作，包括 Vinicius Cerutti 作為 Google Summer of Code 計畫一部分完成的工作，將進一步簡化機器人的操作。

儘管機器人基礎設施最初有一些小問題，但對於如此規模的努力來說，遷移運行得相當順利。絕大多數遷移 PR 在我們開始後的一週內完成，這在 conda-forge 上如此規模的遷移中尚屬首次。最近解決了最大的問題，即修復了 openjdk 配方並從 r-java 中移除了 aarch64 和 ppc64le 建置，使 R 生態系統的最後一大塊得以更新。

展望未來，我們為 R 4.0 遷移所做的改進似乎廣泛適用於其他遷移任務，包括每年的 python 次要版本升級。這些大規模遷移尤其適用，因為它們通常只涉及對 feedstock 本身的少量變更，並且通常在 CI 上失敗，因為會產生損壞的套件。更快的遷移將有助於為下游使用者提供最新的功能，並將過渡時間保持在最短，從而有助於培養生態系統的更高穩定性以及使用者期望從 conda-forge 獲得的無縫體驗。