最初のiOSビルドパイプラインを動かす

ホストに xcodesがまだインストールされていない場合は、チームで承認されたソフトウェア導入手順に従って準備してください。特定のバージョンをインストールする際は、正規に入手した、プロジェクトの要件に合うローカルのXcodeインストーラーを使用します。以下の XCODE_VERSION と XCODE_XIP は、それぞれ確認済みのバージョン番号とインストーラーの絶対パスを表します。インストール中の対話操作を無人実行のビルドタスクに含めないでください。

XCODE_APP にはインストール後の実際のアプリケーションパスを指定してください。CIでは、複数タスクがシステム全体の設定を奪い合わないよう、タスク環境で DEVELOPER_DIRを設定するのがおすすめです。システムのデフォルトのツールチェーンを切り替える必要がある場合は、 sudo xcode-select --switch "$XCODE_APP/Contents/Developer"を実行し、その後 xcodebuild -versionで再確認してください。

選択したXcodeを初回起動し、必要なコンポーネントを準備します。GUIはリモート接続で操作できます。次にXcodeのコンポーネント設定で目的のruntimeをインストールします。 xcrun simctl list devices availableを実行し、テスト対象に合ったシミュレーターを選びます。まず対話的に一度起動し、起動完了を待ってから最小限のテストタスクを実行してください。実機向けのアーカイブとシミュレーターのテストは別の手順です。runtimeがないことをアーカイブ用ツールチェーンの障害と誤認しないでください。

CIログの冒頭でツールチェーンを確認し、少なくともXcodeのバージョン、SDK一覧、コミットIDを出力してください。Xcodeを変更したらキャッシュキーを再生成し、サードパーティー依存関係、署名、エクスポートの手順も検証します。runnerのラベルだけを変更しても、実際のツールパスを確認しなければビルド環境の一貫性は保証できません。

GitLab Runner：ラベルとexecutorを確認

プロジェクトのrunner設定でプロジェクトrunnerを作成し、認証トークンを用意して、 macos、arm64、ios-archive の3つのラベルを設定します。インスタンスのURLと認証トークンを一時的に GITLAB_URL、GITLAB_RUNNER_TOKENに設定し、専用のビルドユーザーでshell executorを登録します。完了後、一時的なトークン変数を削除してください。

プロジェクト変数に実際の IOS_WORKSPACE と IOS_SCHEMEを設定し、次のセクションの署名準備を先に完了してください。ここではアーカイブのみを行い、エクスポートやアップロードは含みません。成果物を7日間保存する設定は一例です。チームの保管ポリシーに合わせて変更してください。証明書、秘密鍵、一時Keychainをartifactsに含めないでください。

GitHub Actions：runnerプロセスは同時に1つのタスクを実行

リポジトリ設定に記載されたrunnerのインストール手順から、macOS ARM64用プログラムを入手し、展開したディレクトリに移動します。 REPOSITORY_URL には現在のリポジトリURLを、RUNNER_TOKEN には今回の登録用トークンを設定してください。タスクが誤ったツールチェーンに割り当てられないよう、登録設定とワークフローの両方に同じラベルを指定します。

リポジトリ変数にツールパス、workspace、schemeを設定します。この例は環境を先に検証できるよう手動実行にしています。署名用の認証情報を持つrunnerを、信頼できない外部コードにそのまま公開しないでください。runnerプロセスは同時に1つのタスクを実行します。concurrency は同じグループ内のワークフロー実行も制御しますが、ホスト単位のリソース制限ではありません。

検証後は、ダウンロードしたプログラムに付属するサービススクリプトで常駐実行を設定し、サービスユーザーと手動テストのユーザーが同じであることを確認してください。署名の準備をあるユーザーで行い、サービスを別のユーザーで実行すると、手動ビルドには成功してもCIから証明書やプロビジョニングプロファイルを参照できないことがあります。

自動化タスク専用のビルドKeychainを用意し、パスワードはCIの保護されたシークレット変数から渡します。証明書をインポートした後は、必要な署名ツールにのみアクセスを許可してください。すべてのアプリケーションに秘密鍵へのアクセスを許可しないでください。以下の確認コマンドでは、現在のユーザーが有効な署名IDを参照できるか確認できます。ただし、プロビジョニングプロファイル、エクスポート設定、プロジェクト設定がすべて一致していることの証明にはなりません。

プロビジョニングプロファイルの保存場所はXcodeのバージョンによって異なる場合があります。現在のツールチェーンが実際に参照するパスを確認してください。インポート後、有効期限、アプリID、署名の種類を確認します。アーカイブに成功してエクスポートに失敗した場合は、Xcodeを繰り返し再インストールするのではなく、エクスポート設定の方式、チームID、プロビジョニングプロファイルのマッピングを重点的に確認してください。

チームでfastlane matchを使用している場合は、既存の暗号化証明書リポジトリとアクセス方針を引き継いでください。検証時は bundle exec fastlane match appstore --readonlyを使用して既存の署名情報を読み込み、ビルドノードがチームの証明書を誤って変更しないようにします。リポジトリのアクセス認証情報、復号パスワード、Keychainパスワードは個別に管理してください。本番署名用の変数は、保護されたブランチまたは管理された手動タスクでのみ使用できるようにします。

タスクの終了後、一時ファイルを削除して一時Keychainをロックします。ログには必要なエラーコードと実行結果のみを残し、秘密鍵の内容、証明書のパスワード、登録トークン、シークレット変数の値は出力しないでください。専用物理マシンでリソースを分離していても、プロジェクト内の認証情報には最小権限を適用してください。

実行します diskutil list と df -hを実行し、容量とマウントポイントを確認してください。正体の分からないディスクに対して、消去やパーティション作成のコマンドを実行しないでください。ビルドユーザーが書き込めるキャッシュディレクトリを作成し、小さなファイルで読み書きをテストします。再起動後のマウント動作を確認してから、常駐runnerで新しいパスを使用してください。

移行前に新しいタスクの受付を停止し、実行中のアーカイブと署名が完了するまで待ちます。DerivedDataは再生成できるキャッシュなので、書き込み中の可能性がある旧キャッシュをコピーするのではなく、新しい場所で再生成するのがおすすめです。以下では明示的に -derivedDataPathを指定するため、ユーザーディレクトリ全体を追加ボリュームに移す必要はありません。

実行前に BUILD_VOLUME を、書き込み可能と確認済みのマウントディレクトリに設定してください。CACHE_KEY はリポジトリ、Xcodeのバージョン、ビルド設定ごとに分けます。BUILD_ID には現在のタスクを一意に識別する値を指定し、別のタスクがアーカイブを上書きしないようにしてください。並列タスクで同じ書き込み可能なDerivedDataディレクトリを共有しないでください。

まずキャッシュを使わずに一度ビルドし、次のタスク以降のキャッシュヒット率とディスク使用量の増加を確認します。アーカイブ、シミュレーターデータ、依存関係キャッシュにはそれぞれ保管ポリシーを設定し、削除前に使用中のタスクがないことを確認してください。ビルド成果物はチーム管理の成果物ストレージに別途保存し、ホストのキャッシュを唯一のバックアップにしないでください。利用期間の終了前にエクスポートし、バックアップを読み取れることも確認します。