GitHub Actions 遷移至 Ubuntu 26.04：用相同 Commit 先確認 Runner 差異
即使沒有修改原始碼，CI 的結果也可能會改變。如果工作流程是交由 ubuntu-latest 執行，那麼作業系統映像檔的切換也必須納入團隊所管理的變更之中。
GitHub 於 2026 年 9 月 17 日宣布正式支援 Ubuntu 26.04 Runner，並公布了 ubuntu-latest 的遷移計畫。本文並非宣傳新映像檔必定更快，而是提出一項實務建議：透過相同的 Commit 來隔離並確認環境差異。
官方公告確認的範圍
根據公告，Ubuntu 26.04 映像檔正式支援 x64 與 arm64，明確標籤為 ubuntu-26.04 與 ubuntu-26.04-arm。ubuntu-latest 預計將於 2026 年 10 月 19 日至 11 月 19 日期間，逐步從 Ubuntu 24.04 切換為 26.04。
新映像檔中有更新或移除的工具，依賴預先安裝套件的建置流程可能會受到影響。GitHub 建議，若尚未準備就緒，可以明確指定使用 ubuntu-24.04。這個時程並不代表所有存放庫的實際切換日期。
記錄存放庫所預期的環境
首先，請檢查工作流程與可重複使用工作流程中的 runs-on。不要因為使用了容器就假設主機的影響會完全消失，最好連在容器外執行的安裝、壓縮、上傳等步驟也一併檢視。
建議在檢查清單中分別列出編譯器、執行階段（runtime）、套件管理器與系統函式庫。與其只寫下工具名稱，不如將其安裝來源以及呼叫該工具的步驟關聯起來，這樣更容易縮小失敗日誌中的問題原因。
相同 Commit、兩種環境、獨立的產出物
遷移演練最好從沒有部署權限的測試路徑開始，這樣最為清晰。在現有映像檔與新映像檔中執行相同的 Commit 和鎖定檔（lockfile），並分別保留記錄檔、測試結果與成品名稱。這正是本文所建議的驗證方式。
在初期比較時，請記錄快取條件，以便區分舊快取的影響。除了建置成功與否之外，還應留下已安裝工具的版本、失敗的步驟以及產出物的執行結果，這樣才能辨別是否僅因快取命中而碰巧通過。
綠色打勾背後仍需進行的驗證
如果是 Web 專案，可以確認產生的檔案是否能實際提供服務；若有原生依賴（native dependency），則可確認其能否在目標環境中載入。與其要求所有產出物的位元組必須完全一致，不如將時間戳記等非決定性差異與功能差異區分開來進行判斷。
審查者應該能夠在一處查看新映像檔的執行連結、工具版本差異、代表性功能檢查結果，以及需要復原的變更。如果在 Runner 切換中混入應用程式的重構，失敗原因與復原範圍將會被不必要地擴大。
固定映像檔的優勢與仍存在的限制
明確指定作業系統標籤有助於掌控重大的切換，但並不代表建置環境完全不可變。請養成明確安裝執行所需工具，並在記錄檔中留下實際版本的習慣。
如果是規模較小的存放庫，不需要重新建立龐大的驗證體系。可以從一個具代表性的建置流程與最敏感的依賴項目開始比較；如果進行了暫時性的版本固定，只要一併記錄解除鎖定的負責人與重新檢視的日期即可。
將公開討論與團隊的決策區隔開來
runner-images 的公開 Issue 是確認映像檔變更事項與回報問題的管道。特定留言或其他專案的失敗並不代表會在我們的存放庫中重現，本文亦不會將社群共識或故障頻率量化為數據來主張。
今天該做的是找出 latest 標籤的使用之處，並在新映像檔中測試相同的 Commit。事先寫下通過標準與保留條件，即使在實際切換期間建置發生變化，負責人也能依據相同的佐證進行判斷。