シンガポール
東南アジアのメンバーが中心のチームにおすすめです。普段使うリモート接続回線と依存関係のダウンロードを、どちらも試して確認しましょう。
連携しやすい時間帯:UTC+8
登録・設定・支払い・割り当ては各約1分、順調なら開通まで約4分です。これは作業時間の目安であり、固定の提供時間ではありません。メールの受信、支払い確認、システムによる割り当ての進捗は、コンソールの表示をご確認ください。
認証コードを受信できるチーム用メールアドレスを用意し、画面の案内に従って登録してパスワードを設定します。注文確認、更新、問い合わせに継続して対応できるメールアドレスを使用してください。認証コードを公開ビルドログに転送しないでください。
Push M4 SまたはPush M4 Lを選び、課金期間とリージョンを指定します。単一アプリの日常的なCIには16GB、複数ターゲットの並列archiveには24GBのプランを検討できます。実際の空き状況はコンソールの最新表示をご確認ください。
USDT-TRC20、またはStripe経由のVisa / Mastercard / Amexを選択できます。利用可能な決済方法はチェックアウト画面でご確認ください。オンチェーン送金ではネットワーク、アドレス、金額を確認し、コンソールで支払いが確認されるまでお待ちください。支払いを開始しただけでは利用開始になりません。
システムによるマシンの割り当て後、注文またはインスタンスの詳細画面でリージョン、接続先アドレス、ポート、ログインユーザーを確認し、SSH/VNCの接続情報を取得します。問い合わせの際は注文番号をお知らせください。ログインパスワードや秘密鍵を送る必要はありません。
5つのリージョンで2種類のマシンを提供しています。まず、普段ビルドマシンを操作するメンバーの所在地から候補を絞り、リポジトリ、依存関係の配布元、成果物ストレージ間の通信経路を確認しましょう。時差が合っていてもネットワーク遅延が小さいとは限りません。VNCでの操作と依存関係のダウンロードは、それぞれ実際にお試しください。
東南アジアのメンバーが中心のチームにおすすめです。普段使うリモート接続回線と依存関係のダウンロードを、どちらも試して確認しましょう。
連携しやすい時間帯:UTC+8
日本の営業時間を中心に作業するチームにおすすめです。runnerのラベルを固定し、ジョブが別のリージョンに誤って割り当てられないようにしましょう。
連携しやすい時間帯:UTC+9
韓国のメンバーがデスクトップを頻繁に操作する場合におすすめです。実際のオフィス回線で画面の応答性を確認しましょう。
連携しやすい時間帯:UTC+9
華南・東南アジアとの連携を重視するチーム向けです。リモートデスクトップとSSHを使い分け、ログはビルドシステムに保存しましょう。
連携しやすい時間帯:UTC+8
北米の日中に操作する必要があるチームにおすすめです。リージョンをまたぐ引き継ぎでは、タスクの時刻をUTCで統一しましょう。
連携しやすい時間帯:UTC−5 / UTC−4
米国東部では季節によって時差が変わります。両方の地域で頻繁に操作する場合は、それぞれの地域に近いマシンを借り、CIキューでタスクを調整しましょう。同じマシンで複数の重いジョブを実行する場合も、並列数の上限を設定してください。
接続先、ポート、ユーザー名はコンソールに表示された値を使い、別の注文の情報を流用しないでください。以下のコマンドでは実際の値を入力します。実行前に、手元の端末でSSHクライアントが使えることを確認してください。
ローカルのターミナルで実行します。初回接続時はホストのフィンガープリントを確認してください。コンソールに照合情報がない場合は、検証を無視せず、先に問い合わせて確認してください。
printf '接続先アドレス:'
read -r MAC_HOST
printf 'SSHポート:'
read -r MAC_PORT
printf 'ログインユーザー:'
read -r MAC_USER
ssh -p "$MAC_PORT" "$MAC_USER@$MAC_HOST"
ログインしたら whoami と sw_versを実行し、ユーザーとシステム情報を確認します。SSH鍵を設定する際は公開鍵だけをアップロードし、秘密鍵は手元のデバイスまたはCIのシークレット管理に保管してください。
デスクトップではGUIのアクセス許可を設定し、コマンドラインでは再現可能なスクリプトを実行します。接続がタイムアウトした場合は、ポート、インスタンスの状態、ローカルネットワークを確認してから問い合わせてください。パスワードを何度も変更しても、ネットワークの問題は解決しません。
初回ビルドでは、ツールチェーン、プロジェクト、署名、書き出しの4項目を確認します。以下のコマンド例はworkspaceを使うiOSプロジェクト向けです。projectのみのプロジェクトでは -workspace を -projectに変更し、プロジェクトで使っているファイル名を指定してください。
アプリケーションフォルダに何がインストールされているかだけでなく、システムで現在選択されているXcodeを確認します。複数のバージョンがある場合は、プロジェクトで決めたアプリケーションパスに切り替え、バージョンとSDKを再確認してください。
xcode-select -p
xcodebuild -version
xcodebuild -showsdks
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
読み取り権限のあるリポジトリのアドレスを入力し、SSH鍵または安全な認証情報管理方法で認証します。アクセストークンをコマンドに直接含めないでください。まずプロジェクトで定められた方法で依存関係を準備し、workspaceとschemeを確認します。
printf 'リポジトリのアドレス:'
read -r REPOSITORY_URL
git clone "$REPOSITORY_URL" app
cd app
git rev-parse HEAD
find . -name '*.xcworkspace' -prune
xcodebuild -list -workspace MyApp.xcworkspace
次の MyApp.xcworkspace と MyApp を、前の手順で確認した実際の名前に置き換えてください。デバイス向けの署名が必要な場合は、対応する証明書とプロビジョニングプロファイルを安全に読み込み、ビルドプロセスからキーチェーンにアクセスできることを確認してください。
mkdir -p build
xcodebuild \
-workspace MyApp.xcworkspace \
-scheme MyApp \
-configuration Release \
-destination 'generic/platform=iOS' \
-derivedDataPath build/DerivedData \
-archivePath build/MyApp.xcarchive \
archive
ExportOptions.plist はプロジェクトで定められた署名・配布設定を使ってください。他チームの設定を流用してはいけません。archiveの作成に成功しても書き出しの成功を意味するわけではありません。各段階の終了ステータスとログを別々に保存してください。
xcodebuild -exportArchive \
-archivePath build/MyApp.xcarchive \
-exportPath build/export \
-exportOptionsPlist ExportOptions.plist
test -d build/MyApp.xcarchive
find build/export -maxdepth 1 -type f -print
コミットSHA、Xcodeのバージョン、実際に使ったscheme、成果物のパスを記録します。初回の失敗では最初のエラーを確認してください。依存関係の解決に失敗したらネットワークとバージョン固定、署名に失敗したら証明書とプロビジョニングプロファイル、書き出しに失敗したら設定を確認します。一度の再試行でリージョン、ツールチェーン、署名設定を同時に変更しないでください。
同じビルドユーザーで手動実行して動作を確認してから、自前のrunnerを登録します。常時稼働によりマシンの電源とホスティングは維持できますが、runnerプロセスの自動起動、証明書の有効性、キューによるタスクの滞留は、チームで設定・確認する必要があります。
利用するCIプラットフォームのプロジェクトまたは組織の設定から、macOS ARM64 runnerのインストール手順を取得します。登録情報は現在のプロジェクトのものを使い、期限切れのトークンは再利用しないでください。ラベルにはリージョン、アーキテクチャ、用途を設定します。
初回はビルドジョブを1つだけ実行します。メモリ、ディスク使用量、所要時間を確認してから並列数を決めてください。マシンを専有できても、すべてのarchiveを同時に開始するのは避けましょう。
GitHub Actions runnerは、展開と登録の完了後、インストール先にある付属のサービススクリプトを使えます。以下はダウンロードや登録のコマンドではありません。先にCIプラットフォームの手順を完了してください。
./svc.sh install
./svc.sh start
./svc.sh status
サービススクリプトで稼働中と表示され、CIプラットフォームでもrunnerがオンラインであることを確認します。LaunchAgentを使う場合、通常はそのユーザーのログインセッションが必要です。無人で起動するにはrunnerの公式サポートに沿って設定・検証してください。「サービスをインストール済み」でも、再起動後に必ずビルドできるとは限りません。
runnerを手動起動したターミナルを閉じ、CIからテスト用のジョブを実行します。実行ユーザー、使用するXcode、キーチェーンへのアクセス、キャッシュディレクトリ、成果物のアップロードを確認してください。無人運用するマシンでは、復旧後のrunnerの状態も検証します。再起動する場合は、他のジョブが実行中でないことを先に確認してください。
専有マシンではDerivedDataと依存関係のキャッシュを保持できます。キャッシュキーには、少なくともツールチェーン、依存関係のロックファイル、ビルド設定を含めてください。成果物を保持する場合は削除ルールを設定し、キャッシュでシステムディスクがいっぱいにならないようにしましょう。