GitLab CI 多個 iOS 簽名任務衝突怎麼辦？2026 排障指南

簽名 Job 互相等待、archive 被覆寫，或同一版程式偶爾簽出不同結果？
本週先把共用簽名資源上的工作串行，再逐項查 Runner 並發、工作目錄與 Keychain；resource_group 只管指定 Job 的並發，不是主機鎖或跨專案隔離。

企業 iOS 發布負責人：多條流水線同時簽名或歸檔，想避免發布互相覆蓋。
平台工程師：在同一台 Mac Runner 執行並行工作，需要釐清調度和目錄邊界。
IT 與安全負責人：要確認共享 Mac 的簽名憑證存取範圍及生產驗收條件。

GitLab CI iOS 簽名任務衝突的排查順序

不要一開始就重跑整條流水線。先保留失敗與成功工作的流水線、Job、Runner 和簽名階段記錄，再比對開始時間、工作目錄、產物路徑與憑證使用方式。你要判斷的是工作是否同時碰到共享狀態，而不是只看錯誤訊息裡有沒有「簽名失敗」。

把問題分成三類會較容易縮小範圍：資源組沒有涵蓋到簽名 Job；Runner 接受並行工作後共用檔案路徑；或憑證與 Keychain 權限本身不正確。建置、測試或 archive 自身失敗也可能呈現為簽名問題，因此要從簽名階段前後的日誌確認因果，不預設團隊的故障率或恢復時間。

建議先做一次只讀盤點：保存相關 Job 設定和 Runner 設定，記下每個工作的實際檢出路徑、archive 輸出位置及使用的簽名身分。不要把憑證值、私鑰或可解鎖 Keychain 的秘密直接複製進排查報告。

調度鎖與 Runner 限制的邊界

resource_group 可以讓使用相同資源組的 Job 避免同時執行；GitLab 文件列出 四種 process_mode，包括 unordered、oldest_first、newest_first 和 newest_ready_first。這些模式影響等待中的工作如何排序，並不會自動替整台主機加鎖，也不代表跨專案共享同一把鎖。GitLab 資源組文件

先逐一核對實際執行簽名、歸檔與發布的 Job 是否使用預期資源組。只在上游測試 Job 設鎖，若後續簽名 Job 沒有納入同一協調範圍，並不能避免簽名階段相撞。若發布順序有要求，檢查目前 process mode 與等待佇列，並驗證較舊的流水線不會在新版本發布後覆寫結果。

Runner 的並行控制另有不同範圍：Runner 設定中的 concurrent 是整體工作數限制，limit 則用於個別 Runner 的工作數限制；兩者不是 resource_group 的替代品。GitLab Runner 進階設定也要對照工作目錄與並行設定說明，確認限制值、執行器及路徑設定與實際 Runner 相符。

工作目錄和產物交叉污染

同一台 Mac 接受多個工作，不必然代表它們共用同一目錄；但如果 builds_dir、Git 檢出路徑、快取或 archive 輸出位置被固定到共用位置，就可能發生檔案覆寫、取到其他工作的中間結果，或讓失敗表現變得難以重現。GitLab Runner 的路徑配置和並行識別方式應以實際 Runner 設定核對，不能只看 .gitlab-ci.yml 的表面設定。

在測試專案讓兩個不含正式憑證的工作同時執行，分別輸出檢出目錄與產物識別資訊，再檢查檔案是否落在不同工作路徑。接著核對快取是否依專案和工作需求隔開，並確認 archive、dSYM 或其他建置產物的來源可追溯；GitLab 對Job artifacts 的保存與取用方式有獨立說明。

若並行測試只在共享 Runner 上重現，而在單工作限制下消失，這是工作目錄或共享狀態的線索，不是憑證安全已獲證明。修正檢出路徑和輸出位置後，應重跑相同測試，而不是只以一次成功的簽名結果結案。

Keychain 與簽名憑證存取

簽名憑證問題要拆成憑證是否存在、私鑰是否可用、Keychain 是否已解鎖，以及 CI 服務帳號能否存取等檢查。Apple 的Keychain 存取控制說明和程式碼簽署與驗證文件可作為核對系統存取邊界和簽署行為的依據，但共享 Mac 上的實際效果仍須在你的執行環境驗證。

先確認每個工作使用哪個服務帳號與簽名身分，再檢查憑證安裝方式、Keychain 解鎖狀態和授權範圍。CI/CD 變數應依 GitLab 的變數安全指引管理，並配合流水線安全文件檢查誰能觸發或修改相關工作。變數已遮蔽，不等於程序已取得隔離；不要用輸出秘密值的方式診斷存取問題。

驗證時使用不含正式私鑰的測試憑證，並記錄允許和拒絕的存取結果。以不輸出秘密值的稽核紀錄確認執行身分；再測試不應取得憑證的工作是否確實無法使用該簽名身分。若無法清楚界定信任範圍，不要讓正式發布 Job 與低信任來源的工作共用憑證環境。

跨專案發布與驗收矩陣

不同專案即使使用相同名稱的 resource group，也不能據此假設它們共用跨專案鎖。GitLab 文件說明了資源組行為與管理方式，但主機上的共同簽名資源仍需由你設計額外協調。也要確認 Runner 的管理範圍與可被哪些專案使用，參照Runner 範圍設定文件核對專案實際設定。

正式放行前，在非生產工作中完成四類驗收：串行簽名、一般並行建置、失敗後重試，以及跨專案呼叫。每一類都要檢查工作順序、產物歸屬和憑證存取記錄；跨專案情境另確認舊工作不會覆寫新發布結果。這些測試用來覆蓋資源組、Runner 路徑與權限邊界，不能只用「簽名命令成功」作為驗收標準。

如果團隊尚未有一致的 Mac 節點管理方式，可先參照VPSMAC 基礎設施說明，再把 Runner 使用範圍、簽名身分和驗收證據寫入內部維運流程。這比只增加重試次數更容易判斷問題究竟出在調度、目錄還是憑證。

常見故障問答

避免簽名工作同時執行

讓會操作同一簽名資源或發布目標的 Job 使用相同 resource_group，並確認鎖涵蓋真正執行簽名和發布的工作。若發布順序重要，選擇符合版本交付語義的 process_mode，再以非生產工作驗證佇列順序。其他未使用該資源組的工作不會因此自動受到主機層限制。

跨專案資源組的鎖定範圍

不要將單一專案的 resource_group 當成跨專案全域鎖。若多個專案共用一台簽名 Mac，需建立額外協調機制，並以各專案的流水線設定和執行記錄驗證鎖的實際範圍。若發布順序不得逆轉，還要確認舊流水線不能覆寫較新的發布結果。

Mac Runner 並發與目錄覆寫

並行工作若落入相同檢出目錄、快取位置或 archive 輸出位置，可能彼此改寫檔案或讀到不屬於自己的中間產物。檢查 Runner 的並發設定與唯一工作路徑，再以同時執行的測試工作核對檢出目錄、快取及產物歸屬；單次成功建置不能證明路徑已隔離。

共享 Mac 上的憑證隔離驗證

使用獨立測試憑證，核對服務帳號、Keychain 存取控制和簽名身分，並記錄允許與拒絕的結果。稽核資料不得包含秘密值；還要測試沒有正式憑證授權的工作是否確實不能簽署。工作能啟動或簽名指令成功，都不足以單獨證明不同工作之間已完成憑證隔離。

依故障邊界選擇 Mac 節點

若你目前以共用 Runner 處理所有工作，增加重試、限制併發或自行維護實體 Mac 都各有代價：重試不能修復錯誤的工作目錄；單純限流可能拉長等待；自行購置與維護設備則需處理硬體管理、更新和閒置容量。若試跑結果顯示正式簽名需與一般建置或其他專案分開，租用專用 Mac 可作為短期驗證隔離邊界的選項；若需要固定長期滿載、實體介面或完全掌控硬體，則應優先評估自購設備。

先用非生產簽名任務重現並驗收並發邊界，再決定是否拆分節點。你也可以閱讀VPSMAC 的 Mac 節點資訊了解遠端 Mac 選項；只有在需要額外簽名環境或試行專用節點時，才考慮 VPSMAC 租賃，並在採用前確認服務條款、存取方式與團隊的安全要求相符。