マシンの利用を開始したら、つまずいている手順から確認しましょう。接続、ツールチェーン、署名、パイプラインを個別に検証し、成功したビルドを再現可能なリリースにつなげます。
アドレス、ポート、ユーザー名、利用開始状況は、コンソールのインスタンス詳細をご確認ください。コマンド内の環境変数はご自身の設定に置き換えてください。実際の接続情報は含まれていません。
「接続」「Xcode」「runner」「支払い」などをお試しください。キーワードを消すと、ガイド全体を再表示できます。
SSHはコマンドラインや自動化に、VNCはGUI操作に使います。どちらも同じ専用物理マシンに接続しますが、接続情報はそれぞれ確認が必要です。
コンソールで対象のインスタンスを開き、ホストアドレス、SSHポート、ユーザー名を確認します。まずローカルで秘密鍵のパスを確認してから接続してください。SSHコマンドにVNCポートを指定しないでください。
chmod 600 "$SSH_KEY"
ssh -i "$SSH_KEY" -p "$SSH_PORT" "$NODE_USER@$NODE_HOST"初回接続時はホストフィンガープリントを確認してください。確認できない場合は、ホスト検証を無効にせず、先にサポートへお問い合わせください。タイムアウトする場合は、ローカルネットワークとポートへの到達性を確認します。アクセス拒否の場合は、ユーザー名、鍵、インスタンスに登録された公開鍵を確認してください。
マシンの再インストールや交換後は、フィンガープリントが変わることがあります。インスタンスに変更があったことを確認してから、ローカルの記録を更新してください。
コンソールに表示されるリモートデスクトップ情報で接続し、アドレス、ポート、パスワードを確認してください。初回接続後に独自のアクセスパスワードを設定し、複数人で同じ認証情報を長期間使い回さないようにしましょう。
デスクトップはXcodeの設定、キーチェーンの確認、シミュレーターの表示に適しています。継続的なビルドはSSHまたはrunnerで実行しましょう。SSHは正常でデスクトップに問題がある場合は、クライアントのエラーとインスタンスの状態を記録し、リモートデスクトップ側から調査してください。最初から何度もマシンを再起動する必要はありません。
SSHトンネル経由でアクセスする場合は、実際のVNCポートに合わせて転送を設定し、クライアントからローカルポートに接続します。
ssh -N -L 5901:127.0.0.1:"$VNC_PORT" \
-p "$SSH_PORT" "$NODE_USER@$NODE_HOST"トンネル接続中はSSH接続を維持してください。利用の可否とポート番号は、インスタンスの設定およびチームのアクセス方針に従ってください。
ノードはシンガポール、東京、ソウル、香港、米国東部の5か所です。対話型デスクトップは主な利用者に近いノードを選びましょう。自動ビルドでは、コードや依存関係のダウンロード経路も考慮してください。複数拠点のチームなら、各拠点の近くにビルドマシンを用意し、runnerのラベルで処理を振り分ければ、全員が同じデスクトップを遠隔操作する必要はありません。
ノードを比較する際は、同じクライアント、ネットワーク、時間帯で、接続の往復時間、リポジトリの取得時間、ビルド全体の時間を記録してください。ネットワーク遅延とコンパイル時間は別の指標です。ネットワーク条件が異なる結果をそのまま比較しないでください。
まずバージョンを記録し、その後に署名を移行します。デスクトップでビルドできても、runnerのユーザーセッションの準備が整っているとは限りません。
異なるバージョンのXcodeにはそれぞれ名前を付け、「アプリケーション」フォルダに配置します。StableとNextは任意のアプリ名です。実行前に、マシン上の実際の名前に置き換えてください。初回起動、ライセンスの確認、必要なプラットフォームコンポーネントのインストールを済ませてから、パイプラインに接続します。
xcode-select -p
xcodebuild -version
xcrun --sdk iphoneos --show-sdk-version
sudo xcode-select --switch \
/Applications/Xcode-Stable.app/Contents/Developer全体設定の切り替えは、ツールチェーンを明示していないジョブにも影響します。複数のブランチを並行してビルドする場合は、ジョブ単位で環境変数を設定し、別のパイプラインによって実行中のジョブの既定バージョンが変わらないようにしましょう。
export DEVELOPER_DIR=/Applications/Xcode-Next.app/Contents/Developer
xcodebuild -version実際にビルドを実行するmacOSユーザーで、署名証明書と対応する秘密鍵をインポートします。次に、使用中のXcodeバージョンの署名設定に合わせてプロビジョニングプロファイルをインストールしてください。証明書だけでは、コード署名を完了できません。
security find-identity -v -p codesigning
xcodebuild -list -workspace App.xcworkspaceプロジェクトのチームID、Bundle Identifier、署名方式、プロビジョニングプロファイルの適用範囲を確認します。同じユーザーで手動のarchiveを一度実行してから、CIで同じコマンドを実行すれば、プロジェクト設定とrunnerセッションの権限のどちらに問題があるかを切り分けられます。
自動化には専用キーチェーンと、管理された鍵の受け渡し手順を使うことをおすすめします。非対話セッションから署名IDにアクセスできるか確認してください。キーチェーンのパスワード、証明書の書き出しパスワード、秘密鍵をリポジトリに登録したり、ビルドログに出力したりしないでください。
以下はワークスペースと共有schemeを使う例です。プロジェクト名、scheme、書き出し設定を置き換えてください。書き出し設定は、プロジェクトの署名方法と配布要件に合わせて用意します。成功メッセージだけでなく、終了コード、ツールチェーンのバージョン、成果物のパスも記録してください。
xcodebuild archive \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-destination 'generic/platform=iOS' \
-archivePath "$HOME/builds/App.xcarchive"
xcodebuild -exportArchive \
-archivePath "$HOME/builds/App.xcarchive" \
-exportPath "$HOME/builds/export" \
-exportOptionsPlist ExportOptions.plistマシンを1人の顧客専用で利用できても、ジョブ同士が自動的に干渉しなくなるわけではありません。ビルドユーザー、ディレクトリ、キューのルールはチームで明確に決めてください。
リポジトリまたは組織のrunner設定で、Apple Siliconに対応したパッケージと登録コマンドを取得し、専用ディレクトリに展開します。設定画面に表示された一時トークンを使い、対象のリポジトリまたは組織に登録してください。トークンをスクリプトに保存しないでください。
./config.sh \
--url "$RUNNER_URL" \
--token "$RUNNER_TOKEN" \
--labels pushmac,macos,arm64
./svc.sh install
./svc.sh start
./svc.sh statusワークフローの runs-on は登録したラベルに合わせます。まず署名資産を使わないテストジョブを実行し、ツールチェーン、作業ディレクトリ、権限を確認してからリリースジョブを追加してください。署名資産を使うrunnerでは、信頼できるコードだけを実行してください。
サービス関連のコマンドはrunnerのインストールディレクトリで実行してください。操作ユーザーとサービスユーザーは同じにします。
チームのGitLabインスタンスの手順に従って互換性のあるrunnerをインストールし、インスタンスが提供する認証情報で登録してください。macOSネイティブのビルドではshell executorを選べますが、ジョブはローカルユーザーの権限で実行されます。実行を許可するプロジェクトやブランチを制限してください。
mkdir -p "$HOME/ci"
gitlab-runner register
gitlab-runner install --working-directory "$HOME/ci"
gitlab-runner start
gitlab-runner statusプロンプトに従って、チームのインスタンスURL、トークン、ラベル、executorを入力します。設定ファイルには認証情報が含まれる場合があるため、アクセス権を制限してください。ログにはジョブ番号とエラーのスタックトレースを残し、環境変数に含まれる秘密情報は出力しないでください。
インストール済みのrunnerバージョンに合ったオプションを使ってください。実行前にローカルのヘルプを確認しましょう。
macOSのユーザー単位のサービスは、通常、ユーザーのログインセッションに依存します。サービスをインストールしても、未ログインの状態で署名ジョブを実行できるとは限りません。runnerが使用するlaunchdのサービス種別、ログイン条件、キーチェーンの利用可否を確認してください。自動起動を優先して、チームのアクセス制御を回避しないでください。
管理された時間帯に、再起動後のサービス状態とビルド全体を確認します。Fastlaneは、たとえば次のようにプロジェクトで固定された依存関係を使って実行します。 bundle exec fastlane ios buildlane名はプロジェクトの定義に従ってください。時差をまたいで作業を引き継ぐ場合は、同じ成果物ディレクトリに複数のarchiveが書き込まれないよう、並列数とキューのルールを明記します。
依存関係の解決、コンパイル、署名、書き出しにかかる時間を個別に記録します。キャッシュの効果を判断するには、同じコミットとツールチェーンで、初回ビルドとキャッシュが効いたビルドを比較してください。
専用物理マシンでは、利用期間中、DerivedData、SPMのダウンロードデータ、CocoaPodsのキャッシュを保持できます。すべてのブランチが同じディレクトリに無条件で書き込まないようにしてください。プロジェクト、ツールチェーン、ジョブの種類ごとにパスを分け、依存関係のロックファイルを保持しましょう。
xcodebuild archive \
-workspace App.xcworkspace \
-scheme App \
-destination 'generic/platform=iOS' \
-derivedDataPath "$HOME/ci-cache/App/stable/DerivedData" \
-clonedSourcePackagesDirPath "$HOME/ci-cache/App/stable/SPM" \
-archivePath "$HOME/builds/App.xcarchive"FlutterやReact Nativeのプロジェクトでは、それぞれのツールバージョンとiOS依存関係のロック状態も揃えてください。問題が発生したら失敗ログを保存してから、該当するキャッシュだけを削除します。ビルドのたびにすべて削除すると、キャッシュが効いたビルドのメリットが得られません。
Push M4 SはM4 / 16GB / 256GBで、単一アプリの日常的なCIに適しています。Push M4 LはM4 / 24GB / 512GBで、より多くのメモリを必要とする場合や複数ターゲットのビルドに適しています。並列実行に適しているかは、プロジェクトで実測したピーク値を基準に判断してください。
+1TB SSDは、依存関係のキャッシュ、複数のツールチェーン、過去の成果物でシステムディスクの空き容量が減ってきた場合に適しています。+2TB SSDは、より多くのプロジェクトキャッシュやarchiveを保持するワークフローに適しています。ストレージの追加でユニファイドメモリが増えるわけではなく、容量に比例してコンパイルが速くなることもありません。
df -h
du -sh "$HOME/ci-cache" "$HOME/builds"まずマウント先を確認してから、キャッシュを移行し、パイプラインの変数を更新してください。追加ストレージはバックアップの代わりにはなりません。archive、シンボルファイル、重要な設定は、チームの方針に従って別途バックアップしてください。
請求期間、ノード、支払い状況はコンソールの表示をご確認ください。サポートへ問い合わせる際は注文番号を記載し、パスワード、秘密鍵、カード番号全体は送信しないでください。
日、週、月、四半期単位で利用できます。Push M4 Sは$19.2/日、$51.8/週、$95.9/月、$260.8/四半期。Push M4 Lは$39.7/日、$107.2/週、$198.5/月、$539.9/四半期です。インスタンスの終了日時、更新方法、利用可能な期間はコンソールで確認してください。日額を掛け算した金額を、他の請求期間の料金として扱わないでください。
リリース前に、ビルドと受け入れ確認に必要な期間を利用期間がカバーしているか確認してください。期間を変更する場合は、コンソールの手順と実際の請求額を確認しましょう。支払い済みの利用期間が自動的に別の期間に切り替わるとは限りません。
ノードの変更では、ネットワーク接続先とマシン環境が変わります。地域ラベルだけの変更ではありません。まずコンソールからサポートへ問い合わせて手順を確認し、コード、署名資産、runner設定、必要な成果物をバックアップしてください。ローカルファイル、キャッシュ、ログイン情報が自動で移行されるとは限りません。
移行後は、ホストフィンガープリント、runnerラベル、署名権限を再確認し、ビルドを一度実行してから旧環境へのジョブの割り当てを停止してください。
お支払いにはUSDT-TRC20、またはStripe経由のVisa / Mastercard / Amexカードをご利用いただけます。すべて米ドル（USD）で決済されます。利用可能な決済方法は、バックエンドに表示される内容をご確認ください。オンチェーンで支払う場合は、その注文に記載されたネットワーク、送金先、金額を使い、古い注文情報を再利用しないでください。
お支払い後は、まず注文状況を確認してください。確認が必要な場合は、注文番号、支払い日時、取引ハッシュまたは決済参照番号をサポートへお知らせください。状況を更新するために再度支払わないでください。
物理ノードは365日稼働します。データセンターが電源、ネットワーク、冷却を管理し、計画停止を設けずに運用します。サービスが稼働していても、プロジェクトのバックアップは必要です。また、利用者側のネットワーク接続が切れないことを保証するものではありません。リモートセッションが切れた場合は、まずインスタンスの状態と別の接続方法を確認し、マシンの異常かどうかを判断してください。
利用期間の終了後、マシンはデータを消去してから次の顧客に提供されます。利用終了前に必要なコード、成果物、設定を取り出し、runnerの登録を解除して関連するアクセストークンを失効させてください。インスタンスを唯一の保管場所にしないでください。
このページでは、すぐに使える操作手順を紹介しています。移行、キャッシュ設計、時差を考慮した役割分担については、記事一覧で詳しい解説をご覧ください。
実際に公開された記事からテーマを選び、詳しい手順と適用条件をご確認ください。ツールチェーンの移行やキャッシュディレクトリの変更前に、現在の設定を記録し、元に戻せる方法を用意してから、一つずつ検証しましょう。
このガイドのコマンドは操作の説明を目的としています。記事で紹介する方法も、リポジトリの構成、署名方針、チームの権限に合わせて実行してください。
アジア太平洋と北米のメンバーが同じ問題を引き継ぐ場合は、単に「接続できない」と書くより、発生時刻とノードを明記すると調査を進めやすくなります。
注文番号またはインスタンス番号、利用ノード、発生時刻とタイムゾーンを記載してください。メンバーごとにネットワークが異なる場合は、それぞれの接続元も記載します。
クライアントのエラー、ビルドコマンド、終了コード、Xcodeのバージョン、関連する最後のログを添えてください。スクリーンショットやテキストを送る前に、秘密情報を削除してください。
SSHとVNCがそれぞれ使えるか、問題を再現できるか、最近変更した設定を記載してください。後から対応する人が同じ確認を繰り返さずに済みます。
コンソールにログインしてサポートチケットを送信し、インスタンスや注文についてお問い合わせください。ログインできない場合は、次のアドレスへメールをお送りください。 support@pushmac.comアカウントのメールアドレスとお問い合わせの内容を記載してください。