BrowserHive の更新

capture-ledger は main ではなく 特定の BrowserHive の版に固定されています。 現在のピンは 19.0.1 です。

これは .upstream/browserhive submodule から来ています。ビルド時に git describe --tags で読んでいるので、このページが古くなることはありません。 submodule が唯一のピンで、BrowserHive 本体・BrowserHive が検証済みの chromium-server-docker・スタックがマウントする SeaweedFS 設定・manifest を照らす OpenAPI 文書（generated/openapi.json）が、すべてこの中に入っています。

以前は 4 箇所ありました

かつては package.json・setup.sh（いまは無い）・compose 2 枚にバージョン文字列が書かれ、 それらが食い違わないか検査していました。submodule が 4 つとも置き換えたので、 同期を保つべき対象がもう存在しません。

手順

# 1. submodule を新しいタグへ動かす。
git -C .upstream/browserhive fetch --tags
git -C .upstream/browserhive checkout <new-tag>
git -C .upstream/browserhive submodule update --init --recursive
git add .upstream/browserhive

# 2. 契約を取り直して型を再生成する（ローカルコピー。ネットワーク不要）。
pnpm run openapi:generate
pnpm run openapi:check     # コミット後に exit 0 になること

# 3. まっさらな状態から作り直す。古いボリュームには前のバケットと DB が残っており、
#    更新で入り込んだ順序の不具合を隠してしまう。
pnpm run stack:down
pnpm run stack:up

# 4. 端から端まで確認する。
pnpm run check
./scripts/prod-smoke.sh

Chromium は自動的に追随します。submodule の submodule なので、 BrowserHive 自身が検証した版がそのまま手に入ります。以前 capture-ledger は これを独立に main で追跡しており、それがスタック崩壊の原因になりました — 上流が開発用 Dockerfile を attic/ へ移した瞬間、すべてのビルドが止まりました。

版の選び方

その版がビルドできるか先に確認する

スタックは submodule から BrowserHive の Dockerfile.prod をビルドするので、 Dockerfile が壊れているコミットを掴むとスタックごと立ちません。実際に一度 起きています。2 度とも同じファイルです: 8a66b72 から b772480 の間は BrowserHive の whitelist dockerignore に COPY 対象が 1 つ足りず、BrowserHive の 8c899dd から a218e94 の間は、消したはずの tsconfig.behaviors.json を COPY が 名指ししたままでした。どちらの区間も "/tsconfig.behaviors.json": not found で失敗します。v11.0.0 はビルドできますが、 2 つ目の区間を指したまま固定すると立ちません。

submodule の更新をコミットする前に確かめてください。

# -f は context ではなく今いる場所からの相対で解決されるので、context を含む
# パスで書くこと。`-f Dockerfile.prod` だと "dockerfile does not exist" になる。
container build -f .upstream/browserhive/Dockerfile.prod -t bh-probe .upstream/browserhive

capture-ledger 側で何が変わるか

API の追加だけの変更 (オプショナルなリクエストフィールドが増える等) なら、手順 2 以外は何も要りません。再生成した型はそのままコンパイルが通り、テストも無修正で 通ります。1.6.0 はまさにこれでした。upstream は変更のたびに前のリリースとの smithy diff を回しているので、項目が増えただけの更新で既存の項目の名前や型が 写しの下から変わることはありません。

厄介なのはインフラの変更です。OpenAPI の差分にはまったく現れません。 1.5.2 → 1.6.0 の移行で実際にあった 2 例:

• BrowserHive の SeaweedFS entrypoint がバケットを自分で作るようになり、capture-ledger 側の一発 init コンテナが不要になった (同時に depends_on による順序保証も 意味を失い、WAIT_FOR_S3 が置き換えた)。
• 上流の Chromium イメージが開発用 Dockerfile を attic/ へ退避させた。

ピンを上げたら、etc/seaweedfs/*・entrypoint・compose の契約に触れる変更が 無いか、上流のリリースノートを読んでください。