2026 年 GitHub Actions macOS Runner：科研團隊選託管還是遠端 Mac？

你提交了 macOS 測試工作流程，卻卡在「要用 GitHub 提供的 Runner，還是準備一台長期在線的 Mac」？

本週建議：先用 GitHub 託管 macOS Runner 執行可自動化的建置與測試；只有需要持久環境、互動式除錯或特定驗收條件時，才評估自管遠端 Mac。若要把遠端 Mac 註冊為自託管 Runner，先審查工作流程信任邊界和憑證權限。

適合沒有實驗室 Mac、要替課程專案或論文配套工具補上 macOS 自動化測試的學生與個人研究者。
也適合需要管理協作權限、維護公開儲存庫，或安排 macOS 發布流程的課題組與實驗室團隊。

先分清楚 GitHub Actions macOS Runner 的三種用法

GitHub 託管 Runner、自託管 Runner 和可互動使用的遠端 Mac 不是同一件事。前兩者說明工作流程由誰提供或管理執行機器；遠端 Mac 則是一種可連線操作的主機，只有完成註冊與設定後，才可能作為自託管 Runner 使用。

簡單說，單純需要把測試自動化，先驗證託管 Runner；需要人操作的 Mac，才考慮遠端主機。自託管 Runner 是一種管理方式，不是「更完整、更安全」的託管方案。

個人研究者：先把課程或論文專案拆成可自動化工作

如果你只有一個論文配套工具、課程專案或小型原型，先列出每次修改後必須重做的檢查：能否編譯、單元測試能否執行、格式或靜態檢查能否自動完成。這些工作能以工作流程描述，就先讓託管 Runner 執行，避免為了第一次 CI 就維護一台常駐主機。

GitHub Actions 工作流程會由事件觸發；推送程式碼、提出合併請求等觸發方式，應按專案需求設定，細節可核對官方工作流程事件說明。你不必先假定所有研究軟體都能在雲端流程中完整測試：先確認依賴是否可安裝、測試是否要求圖形介面，以及資料是否適合進入該執行環境。

場景例子：你的課程工具能透過命令列建置，測試輸入資料也不含受限制內容，先把建置和單元測試放進工作流程。若測試必須在螢幕上操作軟體、手動檢視圖表，便保留本機或遠端互動測試，不必因此把整條 CI 遷到自託管主機。

優點是先從明確、可重複的檢查開始；缺點是自動測試無法代替需要人判斷的圖形介面驗收。若你的下一步常常是登入 Mac、開啟專案、重現錯誤並逐步除錯，就把這些操作需求記下來，再評估持久環境是否值得維護。

課題組：把維運責任和協作方式一起納入選擇

實驗室要共用 Runner 時，決策不只是「誰有 Mac」。還要有人能設定 Runner 註冊、更新相依軟體、處理工作流程故障，並定期檢查誰可以存取主機。依照自託管 Runner 參考文件，自託管 Runner 的安裝與管理由使用者負責；因此，遠端 Mac 並非只要改寫工作流程的 runs-on 標籤就能取代託管 Runner。

你可以先在課題組內確認：

• 誰負責維護：Runner 或研究軟體相依項目更新時，有沒有人能排查工作中斷？
• 環境是否需要保留：下一次測試是否依賴上一次留下的檔案、設定或登入狀態？如果需要，先定義清理和重設方式。
• 誰可以使用：依工作流程來源和協作者權限限制可執行的儲存庫及工作。GitHub 的自託管 Runner 群組存取管理文件說明如何管理 Runner 群組的存取。
• 故障如何處理：若主機離線、工作卡住或測試環境被修改，團隊是否知道由誰檢查及恢復？

若團隊常需互動除錯，且有明確維護人員，自管遠端 Mac 值得評估。反之，若沒人能負責權限和更新，維持託管 Runner 通常更符合團隊的實際能力。

公開儲存庫：先隔離不受信任的工作流程

公開科研軟體可能接收外部貢獻。對自託管 Runner 而言，關鍵問題不是程式碼來自哪位協作者，而是工作流程執行的程式碼能接觸到什麼。GitHub 的安全使用指引提醒，工作流程可能使用可取得的憑證和執行環境資源；因此，不應讓不受信任的程式碼接觸存有研究憑證、共享資料或其他授權的持久主機。

先採用以下做法：

1. 辨認外部輸入：檢查哪些工作流程會因外部貢獻或合併請求而執行。
2. 隔開工作環境：不讓不受信任的工作流程直接使用含研究檔案或共享權限的自託管主機。
3. 縮小憑證範圍：只在確有需要的工作流程中提供所需憑證，並限制可執行的權限。
4. 核對觸發條件：逐一檢查工作流程事件與儲存庫設定，不要只靠「公開專案」或「內部專案」的標籤判斷安全性。
5. 檢查 Runner 群組存取：確認哪些儲存庫和工作流程有權使用自託管 Runner。

若專案必須執行外部貢獻的測試，優先考慮隔離執行環境，並依照 GitHub 安全文件檢視工作流程設計。若無法清楚界定程式碼能取得的檔案、憑證和網路資源，就不要把持久自託管 Runner 暴露給不受信任的工作。

發布團隊：把建置、簽署和人工驗收分開評估

科研軟體要發布 macOS 版本時，先逐項確認建置、測試、簽署、公證和最後驗收各由什麼步驟完成。不要因為發布流程中有人工檢查，就把所有自動化工作都搬到持久 Mac；可以由託管 Runner 執行的工作，仍可留在原有工作流程中。

簽署與公證有各自的流程要求。Apple 的Mac 軟體分發簽署文件及macOS 軟體公證文件可用來核對分發步驟。你應按實際發布方式和憑證處理方法逐項確認，不要把「有一台可連線的 Mac」當成簽署或公證已自動符合要求。

遠端 Mac 可能適合需要互動式驗收、固定操作步驟或持續除錯的流程；但先確認工作流程能否安全地使用憑證，以及團隊能否維護 Runner。若只在發布尾段需要人工操作，就保留這個人工環節，無須把一般建置和測試也一併改成自託管。

用工作流程、權限和維護能力定案

照以下次序檢查，避免先租用或架設主機，再發現工作其實可以自動化：

1. 列出測試項目：分開標記命令列建置、單元測試、圖形介面驗收和人工除錯。
2. 試跑可自動化項目：先用託管 macOS Runner 執行能明確描述的工作，記錄失敗原因。
3. 辨認持久狀態需求：確認測試是否真的需要長期保留設定、檔案或登入狀態，而不是只因方便就保留。
4. 畫出信任邊界：標出外部貢獻者、工作流程可取得的憑證，以及 Runner 可讀取的研究資料。
5. 指派維護責任：確認誰更新主機、管理存取、處理故障，以及在成員離開時回收權限。
6. 再決定是否拆分：自動化測試留在託管 Runner，需要互動除錯的工作交由受控遠端 Mac；只有團隊能承擔自管責任時，才把遠端 Mac 註冊為 Runner。

決策規則：

• 可重複自動化、沒有持久狀態需求：先選 GitHub 託管 Runner。
• 必須互動除錯或保留環境，而且團隊能負責安全與維護：評估自託管遠端 Mac。
• 兩種工作同時存在：拆分工作流程，不要為了統一而把所有任務搬到同一種 Runner。
• 儲存庫接收不受信任的程式碼，且無法隔離主機或憑證：不要讓該工作流程使用持久自託管 Runner。

若你正在評估遠端主機，MangoVM 的資料保護說明可作為檢視資料處理方式的參考；服務方案仍須按你實際需要核對，不能以頁面介紹取代 Runner 安全評估。

常見問題

實驗室沒有 Mac，測試能從哪裡開始？

先將不需要圖形介面的建置和測試寫入 GitHub Actions 工作流程，並確認相依項目能在所選 Runner 環境安裝。需要滑鼠操作或人工判讀的部分，另外安排互動測試；不要把「沒有本地 Mac」等同於所有測試都不能自動化。

遠端 Mac 可以互動使用，是否就能直接跑 CI？

不一定。互動式遠端 Mac 和已設定完成的自託管 Runner 是不同狀態。要跑 CI，還須依官方文件註冊及管理 Runner，確認工作流程、環境和存取權限；並由團隊承擔更新、故障處理和安全責任。

公開專案的自託管 Runner，最先要檢查什麼？

先看外部貢獻者能觸發哪些工作流程，再確認這些工作流程可取得的憑證、檔案和網路資源。若 Runner 存有研究憑證或可讀取共享資料，不要讓不受信任的程式碼使用它；優先隔離工作並套用最小權限。

研究憑證應如何放進自動化流程？

先判斷某個工作是否確實需要憑證，再限制可取得憑證的工作流程和權限，並確認憑證不會暴露給不受信任的程式碼。自託管主機如能讀取研究檔案或共享資源，更應一併檢查主機存取方式與工作流程觸發條件。

如果你的痛點已從自動化測試轉為「需要一台可持續連線、能逐步操作和除錯的 Mac」，現有方案可能卡在缺少互動介面、環境無法延續，或每次排查都要重新準備主機；自管實體機則會增加更新、可用性和權限管理工作。這時可查看 MangoVM 遠端 Mac 方案，先核對租用方式、連線需求與你的工作流程，再決定是否適合用租賃補上互動式 macOS 環境；若團隊沒有持續維護和安全管理能力，仍應把 CI 留在託管 Runner。

常見問題