Vivarium
  • 日本語

      • 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）—unreproducedbranch-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.jsonbranch_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 テーブルを書き込む （実行ページで確認できる）:

      originalbranch-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 イメージは存在しない。
      • プライベートレジストリへの認証。 v1 では提供されたイメージ参照が 匿名でプル可能であることを前提とする。

      関連情報

      • 比較ページ — このパイプラインのアーティファクトバンドルを 消費する R.3 のサイドバイサイド UI（file-drop、URL パラメータ、JSON paste の 3 経路）。
      • Contract v1 — このパイプラインが出力・消費する verdict サーフェス。
      • verdict.schema.json — バンドルの両エントリが検証に使用するスキーマ。
      • Consumer workflow — コンシューマーリポジトリの CI で Vivarium レシピを検証するための兄弟再利用可能ワークフロー。
      • Layer 2 カタログ — inputs.slug に使用できるスラッグ。