まず確認、必要なら相談

まず xcode-select -p と xcodebuild -versionを実行し、現在の開発者ディレクトリとバージョンを記録します。目的のXcodeがインストールされていることを確認してから、開発者ディレクトリをその Contents/Developerに切り替えてください。以下のパスはアプリ名がXcode.appの場合に使えます。ノード上のアプリ名にバージョン番号が含まれる場合は、実際のパスに置き換えてください。

xcode-select -p
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -version

CIプロセスは、 DEVELOPER_DIR でシステムの選択を上書きしている場合があります。ターミナルとパイプラインでバージョンが異なる場合は、システム設定だけでなく、jobの環境変数とrunnerのサービスユーザーを確認してください。特定のタスクで別のバージョンが必要な場合は、そのタスク内で開発者ディレクトリを明示的に指定し、同じノード上の他のビルドに影響しないようにしましょう。

まずディスク使用量を確認し、削除するか判断します。ツールチェーンの切り替え後にキャッシュ関連のエラーやインデックスの異常が発生した場合、またはディスク容量が不足している場合は、DerivedDataを整理できます。通常のコンパイルエラーを、最初からキャッシュが原因だと決めつけないでください。関連するビルドタスクを終了してから、キャッシュディレクトリを削除せずに名前を変更しておくと、切り戻しがしやすくなります。

du -sh "$HOME/Library/Developer/Xcode/DerivedData"
mv "$HOME/Library/Developer/Xcode/DerivedData" "$HOME/Library/Developer/Xcode/DerivedData.backup.$(date +%s)"

ディレクトリが存在する場合にのみ名前を変更してください。次回のビルド時にXcodeがキャッシュを再作成します。名前を変更しただけではディスク容量は空きません。新しいビルドが正常に完了したことを確認してから、実際のバックアップパスにある古いキャッシュを削除してください。必要なアーカイブは残し、Archives、プロジェクトディレクトリ、署名関連ファイルをまとめて消さないでください。CIで独自の -derivedDataPathを指定している場合は、現在のユーザーのデフォルトディレクトリではなく、そのパスを確認してください。

署名には、有効な証明書と対応する秘密鍵の両方が必要です。通常、証明書ファイルだけでは署名できません。使用権限のある署名関連ファイルをキーチェーンアクセスで読み込み、実際にビルドを実行するユーザーで利用可能なIDを確認してください。証明書ファイルや読み込み用パスワードをチケットに記載しないでください。

security find-identity -v -p codesigning
security list-keychains -d user

対話型ユーザーにIDが表示されても、runnerのサービスユーザーから見えるとは限りません。サービスの実行アカウント、キーチェーンの検索リスト、ロック解除状態、アクセス権を確認してください。キーチェーンのアクセス制御を変更する場合は、必要な署名ツールだけに許可を与えてください。一度のエラーを解消するために、すべてのアプリに秘密鍵へのアクセスを許可しないでください。チケットには、機密情報を除いたIDの確認結果、エラーコード、実行ユーザーの種類を記載してください。

SSHターミナルだけでなく、失敗したjob内でも同じ環境チェックを実行してください。実行ユーザー、開発者ディレクトリ、Xcodeのバージョン、PATH、利用可能なシミュレータを比較します。サービスプロセスは対話型シェルの設定を読み込まない場合があるため、手動で実行できてもサービス環境が同じとは限りません。

whoami
xcode-select -p
xcodebuild -version
printf '%s\n' "$PATH"
xcrun simctl list devices available

シミュレータ一覧に目的のデバイスがない場合は、必要なランタイムがインストールされているか、テストタスクのdestinationが一致しているかを確認してください。runnerがオフラインの場合は、サービスの起動状態とタスクログを確認してから、ネットワーク接続と登録情報を確認します。比較基準がない場合は、まずビルドを一つ実行して手順を検証し、統合メモリとディスクの使用量を見ながら並列実行数を段階的に増やしてください。

専有とは、物理リソースを他の利用者と共有しないことです。同じノード上の複数タスクが互いに影響しないという意味ではありません。GitHub ActionsとGitLab CIの詳しい接続手順は、接続ガイドをご覧ください。

ウォレットでの送金表示、ブロックチェーン上の承認、注文の照合はそれぞれ別の段階です。確認にかかる時間は、ブロックチェーンの処理状況と決済ゲートウェイの状態によって異なります。このページでは所要時間を保証していません。まず支払いページに記載されたネットワーク、送金先アドレス、金額を確認してください。次に取引が成功しているかを確認し、最後にコンソールで注文状況を確認します。

注文状況が更新されていないからといって、再度支払わないでください。手動での照合が必要な場合は、注文番号、トランザクションハッシュ、送金額、送金時刻を、タイムゾーンとともにお知らせください。トランザクションハッシュは取引の特定に使用します。シードフレーズ、ウォレットの秘密鍵、パスワードは不要です。絶対に送信しないでください。指定されたネットワークや金額と異なる送金をした場合は、取引記録を保管し、チケットに正確に記載してください。

まず決済ページのエラーメッセージと注文状況を確認し、カード発行会社が該当する米ドル決済を許可しているか、追加認証が必要かを確認してください。カード発行会社に保留中の利用承認が表示されても、注文の支払いが完了したとは限りません。カードの通知だけでサービスの利用開始状況を判断しないでください。

決済に何度も失敗する場合は、短時間に連続して再試行せず、カード発行会社に拒否理由を確認してください。コンソールで支払いが未確認なのに銀行側で引き落としが表示されている場合は、注文番号、決済時刻、金額、機密情報を除いたエラーメッセージをお知らせください。決済取引IDがあれば、あわせてご提示ください。カード番号全桁、セキュリティコード、認証SMSは送信しないでください。サポートが注文と決済記録を照合します。返金や利用承認の解除状況は、決済ゲートウェイとカード発行会社の結果に基づいて確認します。

まずコンソールに表示された利用期限をご確認ください。通知の送信時期と配信状況はコンソールで確認できます。このページでは、期限の何日前に通知されるかを保証していません。また、通知を受け取ることだけを利用継続の判断基準にしないでください。チームのプロジェクトカレンダーにも期限を登録し、更新結果を確認する担当者を決めておくことをおすすめします。

日、週、月、四半期から期間を選んだら、更新請求の機種、追加オプション、利用期間を確認してください。支払い後は注文状況が更新されたことを確認し、決済ページのスクリーンショットだけに頼らないでください。期限までに更新しないとノードを利用できなくなる場合があります。プロジェクト、成果物、必要な設定は期限前にバックアップしてください。コンソールの日時や金額が想定と異なる場合は、請求書番号を控えてチケットを送信してから、支払いを続けるか判断してください。

各利用期間の料金とストレージ拡張料金は、プランページをご確認ください。既存の注文に関する料金の確認はコンソールからチケットを送信してください。メールにマシンのパスワードを添付しないでください。