Branch-fix verdict パイプライン

コントリビューターが提供したブランチフィックス Docker イメージの Contract v1 verdict をキャプチャし、デプロイ済みの元の verdict と並べてサイドバイサイド比較を提供する workflow_dispatch GitHub Actions ワークフロー。

ワークフローは .github/workflows/branch-fix-verdict.yml に配置されている。

5 行の呼び出し例

gh workflow run branch-fix-verdict.yml \
  --repo aletheia-works/vivarium \
  -f slug=bash-local-shadows-exit \
  -f branch_image=ghcr.io/contributor/bash-fix:branch-x \
  -f expected_verdict=unreproduced

実行ページには Markdown 比較サマリーがレンダリングされ、キャプチャした verdict は branch-fix-verdict-<slug>-<run_id> という名前のワークフローアーティファクトとしてダウンロードまたはプログラム的なフェッチ用にアップロードされる。

インプット

インプット	型	必須	デフォルト	目的
`slug`	文字列	✅	—	`src/layer2_docker/` 以下のレシピスラッグ（例: `bash-local-shadows-exit`）。スラッグはワークフローのチェックアウト時にツリー内に存在しなければならない。タイポがあればワークフローは早期に失敗する。
`branch_image`	文字列	✅	—	検証する Docker イメージ参照（例: `ghcr.io/contributor/foo-fix:branch-x`）。ランナーが認証なしにプルできなければならない。プライベートレジストリサポートは追加作業。
`expected_verdict`	選択肢（`reproduced`\|`unreproduced`）	—	`unreproduced`	branch-fix イメージに対してコントリビューターが期待する verdict。`unreproduced`（バグが再現されない）が典型的な「修正が機能している」答えだ。ワークフローの最終ステップはキャプチャした verdict がこれと一致するかアサートし、一致しない場合はゼロ以外で終了する。
`original_image`	文字列	—	（空）	オプションのオーバーライド。デフォルトではワークフローは GitHub Pages からデプロイ済みの元の verdict をフェッチする——イメージを再実行するより安価で、ギャラリーが提供するものと同一だ。`original_image` を指定すると代わりにそのイメージから再キャプチャする。特定のタグへの比較をアンカーしたいときやプライベートフォークのテストに有用。

Verdict セマンティクス（リマインダー）

reproduced はこの実行でアップストリームバグが再現されたことを意味する。 unreproduced は再現されないことを意味する。完全な説明は Contract v1: Verdict セマンティクスを参照。

元の verdict が reproduced のレシピに対して、成功した branch-fix は verdict を unreproduced に反転させることが期待される。元の verdict がすでに unreproduced （アップストリームの修正検知イベントを追跡するセンチネルページ）のレシピに対しては、コントリビューターはこのワークフローをほとんど必要としない。

アーティファクト

ワークフローは 30 日保持のディレクトリアーティファクトを branch-fix-verdict-<slug>-<run_id> という名前でアップロードする。バンドルには以下が含まれる:

ファイル	ソース	注記
`branch-fix-verdict.json`	`branch_image` からライブキャプチャ。	常に存在。Contract v1 に準拠し `verdict.schema.json` に対して検証パスする。
`original-verdict.json`	デフォルト: `https://aletheia-works.github.io/vivarium/repro/<project>/<issue_path>/verdict.json` からフェッチ（`recipes.json` 内エントリの `page_url` に `verdict.json` を付加した形）。`original_image` を指定した場合: そのイメージからキャプチャ。	デプロイ済みの Pages スナップショットが 404 を返す場合（例: まだライブサイトにない新しいレシピ）は省略。

R.3 比較ページ UI はこのバンドル構造を正確に消費する。このようにファイルに名前を付けることで、R.2 が R.3 のプログラミング対象となるワイヤーフォーマットにコミットする。

比較サマリー

ワークフローは $GITHUB_STEP_SUMMARY に Markdown テーブルを書き込む（実行ページで確認できる）:

	original	branch-fix
verdict	（例）`reproduced`	（例）`unreproduced`
exit code	（例）0	（例）1

続いて expected_verdict アサーションの「期待通り」/ 「期待と不一致」を 1 行で記述する。Markdown サマリーはワークフロー実行ページ上の at-a-glance ビューだ。サイドバイサイド比較サーフェスが必要なら、ワークフローのアーティファクト zip を比較ページに file-drop または paste で渡す。どちらにしてもアーティファクトが真実のソースだ。

このパイプラインがしないこと

branch-fix イメージのビルド。 コントリビューターはランナーがプルできるレジストリに自分でビルドして公開することが期待される。イメージはこのパイプラインの入力境界だ。
Layer 1 (WASM) 再現の検証。 Layer 1 の verdict はブラウザによってページ内でライブ生成される。スワップできる Docker イメージは存在しない。
ホスト型ランナーでの Layer 3 (rr replay) 再現の検証。 GitHub ホスト型 Ubuntu ランナーは rr replay を駆動できない。 Layer 3 branch-fix 検証には CPUID フォールティングを公開するセルフホストランナーが必要だ。
プライベートレジストリへの認証。 v1 では提供されたイメージ参照が匿名でプル可能であることを前提とする。

#Branch-fix verdict パイプライン

#5 行の呼び出し例

#インプット

#Verdict セマンティクス（リマインダー）

#アーティファクト

#比較サマリー

#このパイプラインがしないこと

#関連情報