2026 リモートMacとGitLab Runner シェルエグゼキュータ、ランナータグ、キャッシュと同時実行 — Jenkins・GitHub Actionsとの比較

登録前に：レビューで「リモートMac上のGitLab Runner」を壊す7つの前提

GitLabのドキュメントではgitlab-runner registerが滑らかに見えますが、本番では時間はしばしばAppleツールチェーンの状態機械と同時ディスク衝突で溶けます。以下の7項目で「ランナーを足す」ことを、署名できるリスク表に変えます。

1. 01

   リモートMacをLinuxランナー同然に扱う：TCC・キーチェーン・時折必要なGUIを無視すると初回署名が破綻します。SSHとVNCのチェックリストとあわせてレビューしてください。

2. 02

   個人のmacOSアカウントで登録する：スリープ・アップデートプロンプト・デスクトップセッションが真の無人フローを壊します。再現可能ビルドに沿った専用CIユーザーにしてください。

3. 03

   同時実行をCPUコアだけで決める：XcodeのRAMスパイクとNVMe書き込み増幅が先に噛みます。DerivedDataをバケット化しなければ2ジョブがデッドロックします。SwiftPM／Podsディスク運用と同じ契約です。

4. 04

   ランナートークンと登録衛生を軽視する：config.tomlのバックアップを平文のように散らすと、ローテーション当日にキューが赤くなるとき誤った安心だけが残ります。

5. 05

   キャッシュ方針をコピペする：悪いcache:キーはブランチ間汚染か常時ミスを招きます。ブランチとロックファイル次元でキーを設計します。

6. 06

   成果物をランナーディスクだけに置く：GitLabの成果物やオブジェクトストレージがなければディスクとコンプライアンスの両方が痛みます。保持はセキュリティレビューに結び付けます。

7. 07

   「最初の人間の窓」がない：初期署名プロファイルはヘッドレス復帰前に一度だけVNCやデスクトップ確認が要る場合があります。Fastlane＋CIを参照してください。

共通の根は、「リモートMac」を生の計算資源ではなくXcodeフィンガープリントとキーチェーン境界を持つホストとして扱わないことです。イメージフィンガープリント・ツールチェーン版・クリーンアップの水位・ランナータグ契約を、レプリカのように保守します。エンタープライズビルドプールと組み合わせてください。複数プロジェクトが同一ホストを共有する場合、GitLabのtagsは「どれかのMac」より細かくなければ、resource_groupは真の分離を表現できません。

GitHub Actionsとの差は「コンパイルできるか」ではなくパイプライン定義とイベントソースです。.gitlab-ci.ymlはMRライフサイクルにネイティブに結び付き、ActionsはPRに結び付きますがGitHubからの移行コストが高いです。GitLab一択なら、macOSをシェルランナーにする方がiOS向けに第二のJenkins方言を維持するより一貫しがちです。それでもオンプレオーケストレーションのレビューではJenkinsが勝ることもあります。次の表がトレードオフを固定します。

登録前にランナーガイドのキャッシュとラベル節を読んでください。多くのディレクトリ契約はGitLabのcacheとCI_PROJECT_DIRにそのまま写ります。変わるのはワークフローからパイプラインへのトリガーだけです。

6段階：専用リモートMacをGitLabシェルランナーとして登録し、最初のグリーンパイプラインに到達する

順序が重要です。まず身元とディレクトリ、次に登録とタグ、最後に同時実行です。再現可能ビルドにフィンガープリントスクリプトを揃え、GitLabが「git cloneが動く」だけでなく安定署名を検証できるようにします。

1. 01

   専用ユーザーと作業ルートを作る：例：/Users/ci/gitlab-runner。個人の~/Desktopと混ぜない。SSHは鍵のみ。

2. 02

   gitlab-runnerをインストール：公式macOSパッケージまたはHomebrew。PATH上のバイナリがサービスアカウント（launchd）下で動くこと。

3. 03

   registerを実行：shellエグゼキュータを選び、GitLabのURLと登録トークンを渡す。tag_list（例：ios,shell,m4）を対話または非対話フラグで固定。

4. 04

   最初のヘルスチェックジョブ：xcode-select -p、xcodebuild -version、swift --version、ディスクスナップショットを出力。ログをランナー受入証跡として保存。

5. 05

   .gitlab-ci.ymlでDerivedDataを明示：SwiftPM／Podsディスク運用と同じ契約 — プロジェクトごとにバケット化し、デフォルト共有パスを避ける。

6. 06

   タイムアウト・成果物・クリーンアップを定義：timeout、失敗時保持、ディスク低下時の停止ライン（監視＋ランナー停止API）。

stages: [build]

variables:
  DERIVED_DATA: "$CI_PROJECT_DIR/.derivedData/$CI_PIPELINE_ID"

build_ios:
  stage: build
  tags: [ios, shell, m4]
  timeout: 45m
  script:
    - xcode-select -p
    - xcodebuild -version
    - df -h
    - xcodebuild -scheme "App" -configuration Release -destination "generic/platform=iOS" -derivedDataPath "$DERIVED_DATA" build
  artifacts:
    when: on_failure
    paths:
      - "**/*.xcresult"
    expire_in: 3 days

GitLabまたはランナーアップグレード時は同一コミットで前後のカナリアiOSジョブを走らせ、フィンガープリント出力とビルド時間分布を比較します。ランナーキャッシュとの対比：緩すぎるGitLabキャッシュキーはブランチAがBのPodsキャッシュを汚染し、厳しすぎるキーは冷起動の連続を意味します。プラットフォームとプロダクトが保持ティアで合意する必要があります。

プロバイダが固定SSHポートと非rootユーザーを渡すなら、接続パラメータは散在する変数説明ではなく内部ランブックに集約し、ローテーションは一か所で。Jenkins＋リモートMacと併せ、SSHベースライン（鍵・ファイアウォール・監査）はCIスタック横断で単一ソースにし、三つの方言にしないでください。

レビュー向け参照数値（内部すり合わせ）

以下の箇条書きは内部すり合わせ用です。しきい値はリポジトリ規模と並列度に合わせて調整します。

• ディスク余裕：定常負荷で≥20％の空きを維持。しきい値未満ではスケジューリングを止めて先に掃除し、削除パスを監査用に記録します。
• 同時実行プローブ：単一ジョブのピークRAMを基準にし、同時実行を増やしながらP95を見ます。Apple Siliconではコンパイル／リンクのピークが平均を大きく上回ることが多いです。
• ランナー受入ログ：gitlab-runner --version、xcodebuild -version、CocoaPods利用時はRuby／Bundler、ディスクモデルを記録。変更後はカナリアパイプラインを起動します。

オフィス専用Macはスリープ・ネットワークジッター・ツールチェーンドリフトに悩まされます。LinuxはApple公式のiOSツールチェーンをホストできません。慣れたWeb／MRワークフローでGitLabを保ちつつ、macOS実行を専用・常時稼働・SSH到達可能なリモートノードへ移すと、「パイプライン真実の単一ソース」がスローガンから契約になります。アドホックな自社ハードや脆い仮想化Xcodeスタックと比べ、SSHエンドポイント・ディスク階層・再現可能なランナープロファイルが明確なNodeMini Mac Miniクラウドレンタルの方がしばしば強いプラットフォーム手です。仕様と料金はレンタル価格で比較し、オンボーディングはヘルプセンターで仕上げます。

本ランブックを内部ツールチェーン変更ティアに結び付けます。Xcodeパッチ／マイナー／メジャーアップグレードは承認範囲・カナリア範囲・キャッシュ無効化方針が異なります。