GitHub Actions Environment 如何接入 iOS 簽章發布？2026

GitHub 官方文件明確指出，引用 Environment 的 job 必須通過部署保護規則才會送往 Runner，而該 Environment 的 Secrets 也要等規則通過後才可供 job 使用；這兩道控制適合放在真正執行生產簽章與發布的工作上，不應取代 Mac 主機隔離。GitHub 部署環境文件

本週建議動作：先分開 PR 檢查、一般建置與正式發布，再把生產憑證交給受保護的發布 job，並以實際核准、拒絕及 Runner 路由記錄驗收。

企業 IT 負責人：需要把 iOS 簽章發布審批接入既有 GitHub Actions 治理流程。
平台工程與技術主管：需要確認環境 Secrets、Mac CI Runner 與正式簽名身份之間的信任邊界。

發布流程應拆成不同信任層級：PR 檢查只處理不可信變更，一般建置產出待驗證的建置結果，正式簽章與發布則使用受限的憑證和可信 Mac 節點。審批門禁應落在最後這類真正需要生產權限的 job，而非籠統地套用到整條工作流程。

在設定前，先記錄工作流程由什麼事件觸發、允許的目標分支或標籤、簽名資產存放位置，以及誰對發布負責。這份基線可協助團隊分辨「工作流程被觸發」與「工作已獲准取得生產環境資源」，也方便事後追查例外。

Environment 保護規則管的是部署工作能否繼續；它本身不會替工作流程判定程式碼是否可信，也不會清除已執行工作的主機狀態。規則的適用範圍及可用設定，應以目前儲存庫可見性、方案與官方文件為準，勿將公用儲存庫的條件直接套用到私有儲存庫。

在儲存庫的 Environment 設定中建立正式發布環境，依企業政策配置部署分支或標籤限制及人工核准人。若政策要求禁止發起人自行核准，或限制管理員略過保護規則，應將這些例外逐項檢查；「已啟用審批」並不足以證明例外路徑也受到控制。GitHub 部署環境與保護規則說明

工作流程中的 environment 應由正式發布 job 引用。GitHub 的工作流程語法分別定義 job 的執行環境與 runs-on Runner 選擇；兩者解決的問題不同，不能因為 job 引用了 Environment，就假設它一定會送到正確的 Mac 節點。GitHub 工作流程語法

先讓不需要生產簽名身份的建置或測試工作完成，再由有明確依賴關係的發布 job 承接簽章工作。以下示例只呈現工作之間的關係；Runner 標籤、觸發事件和憑證名稱須依團隊實際設定調整。

jobs:
  build:
    runs-on: macos-build
    steps:
      - run: echo "執行一般建置與測試"

  release:
    needs: build
    runs-on: [self-hosted, macOS, production-signing]
    environment:
      name: production
    steps:
      - run: echo "核准後執行正式簽章與發布"

needs 表達建置工作完成後才可接續發布；environment 則使正式發布工作受該環境保護規則管理。上線前應從執行記錄確認：等待核准時發布 job 的狀態符合預期，遭拒時發布步驟沒有繼續，且核准前該 job 未被送往 Runner。環境部署記錄亦應能對應到實際發布工作。

PR 工作與正式發布工作應採用不同的觸發條件與憑證邊界。若工作流程使用 pull_request_target，必須特別留意其安全使用限制，避免在具備敏感權限的情境下執行來自不可信 PR 的程式碼。GitHub 對 pull_request_target 的安全說明

對只負責編譯和測試的工作，若不需要正式簽名身份，就不應因方便而共用發布工作使用的 Runner 或憑證。若必須共用主機，須將殘留工作區、同機工作及主機受損後的影響納入風險評估，而不是把不同 macOS 帳號名稱視為隔離證明。

Environment Secrets 的主要作用，是讓引用該環境的工作在保護規則通過後取得環境層級的 Secrets。它不會自動限制倉庫或組織層級的其他 Secrets；發布憑證應只由確實需要它的工作引用，並記錄憑證建立、保存、授權與撤銷的負責人。

iOS 代碼簽名身份涉及憑證及其對應私鑰。團隊應清楚記錄兩者的存放與使用方式，並確認簽章工作所使用的 Keychain 不會因工作取消或失敗而留下可被後續工作沿用的憑證狀態。Apple 對代碼簽名憑證與私鑰的說明

接著核對發布 job 的 runs-on、Runner 標籤與 Runner group。GitHub 的 Runner group 可用於限制哪些工作流程有權使用群組中的 Runner；團隊須確認非可信 PR 與一般工作流程不能透過其他路由接觸生產簽章節點。GitHub Runner group 存取控制

自託管 Runner 不保證每次工作都在臨時、乾淨的隔離虛擬機中執行，因此持久化 Mac 還須有工作區清理、節點停用及主機受損後的處置流程。GitHub 新增自託管 Runner 的安全說明 這是 Environment 與主機安全之間的重要分工：前者管發布准入和 Secrets 時機，後者仍由 Runner 管理與主機運維負責。

• [ ] 記錄 PR 檢查、一般建置與正式發布各自的觸發來源、分支條件及憑證需求。
• [ ] 在正式 Environment 設定部署保護規則，核對部署分支或標籤、自我核准及管理員略過等政策例外。
• [ ] 確認只有正式發布 job 引用該 Environment，並透過 needs 或相應依賴關係限定發布順序。
• [ ] 驗證核准前工作不會被送往 Runner，核准後才可使用 Environment Secrets；另行檢查倉庫與組織層級 Secrets 的存取範圍。
• [ ] 確認正式發布 job 被路由至允許的 Mac Runner group 與節點，並驗證一般工作流程及未審核 PR 無法接觸該路徑。
• [ ] 演練符合條件的發布、核准拒絕、未允許的分支、發起人自行核准、管理員略過、工作流程失敗與取消等情境，保存執行及部署記錄。
• [ ] 指定簽名憑證撤銷、Keychain 清理、節點隔離及主機復原的責任人，確認發布失敗後簽章工作不會意外接續。

核准前，正式發布工作會先在 Mac Runner 上等候嗎？
依 GitHub 對 Environment 的說明，引用環境的 job 通過保護規則前不會被送往 Runner；Environment Secrets 也要在規則通過後才可供該 job 使用。團隊仍應查看實際執行狀態與 Runner 記錄，避免只憑介面顯示推定路由結果。

私有儲存庫是否一定能使用相同的 Environment 保護設定？
不能直接假設。可用的保護規則會受儲存庫可見性與目前方案條件影響；設定前應以 GitHub 現行文件和儲存庫介面逐項核實。若必要的核准或限制不可用，應先調整發布架構或治理條件，而非把未受控的工作視為等效門禁。

Runner group 與 Environment 可以互相取代嗎？
不可以。Environment 管理部署工作准入及環境 Secrets 的使用時機；Runner group 管理工作流程可使用哪些自託管 Runner。正式發布須同時檢查兩者，並確認標籤、群組政策和工作流程觸發條件沒有留下另一條可接觸簽章主機的路徑。

拒絕或取消發布後，應由誰處理簽章環境？
發布負責人應確認工作已停止，Runner 管理者檢查工作區與 Keychain，憑證管理者則依事件嚴重程度撤銷或重新授權憑證。若取消後狀態不明，應先隔離節點並調查執行記錄，再恢復正式發布；不能只依賴 Environment 的拒絕結果推定主機已清理。

當上述驗收完成，團隊即可依實際工作負載決定正式簽章任務由自有 Mac 或遠端 Mac 承接。自購節點可提供實體資產控制，但也須自行負擔採購、維護與閒置期間成本；一般雲端執行環境則未必能滿足 macOS 簽章所需的真實 Mac 節點條件。若團隊要為獨立的生產發布任務試行遠端 Mac，可先查閱 JEXCLOUD 遠端 Mac 部署與使用資訊，再按實際可用節點、存取方式與交付條件評估，並透過 JEXCLOUD 服務方案頁面核對目前選項；若發布流程需要長期固定負載或實體介面，自行部署可能更合適。