Bazel レジストリ

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

Bzlmod は、Bazel レジストリ（Bazel モジュールのデータベース）から情報をリクエストすることで、依存関係を検出します。現在、Bzlmod は特定の形式に従ったローカルディレクトリまたは静的 HTTP サーバーであるインデックスレジストリのみをサポートしています。

インデックスレジストリ

インデックスレジストリは、モジュールのリストに関する情報（ホームページ、メンテナー、各バージョンの MODULE.bazel ファイル、各バージョンのソースを取得する方法など）を含むローカルディレクトリまたは静的 HTTP サーバーです。特に、ソースアーカイブ自体を提供する必要はありません。

インデックスレジストリは次の形式にする必要があります。

/bazel_registry.json: レジストリのメタデータを含む JSON ファイル。例:
- mirrors: ソースアーカイブに使用するミラーのリストを指定します。ミラーリングされた URL は、ミラー自体と、その source.json ファイルで指定されたモジュールのソース URL（プロトコルを除く）を連結したものです。たとえば、モジュールのソース URL が https://foo.com/bar/baz で、mirrors に ["https://mirror1.com/", "https://example.com/mirror2/"] が含まれている場合、Bazel が試す URL は https://mirror1.com/foo.com/bar/baz、https://example.com/mirror2/foo.com/bar/baz、最後に元のソース URL https://foo.com/bar/baz の順になります。
- module_base_path: source.json ファイルで local_repository 型のモジュールのベースパスを指定する
/modules: このレジストリ内の各モジュールのサブディレクトリを含むディレクトリ
/modules/$MODULE: このモジュールの各バージョンのサブディレクトリを含むディレクトリ。次のものも含まれます。
- metadata.json: モジュールに関する情報を含む JSON ファイル。次のフィールドがあります。
  - homepage: プロジェクトのホームページの URL
  - maintainers: JSON オブジェクトのリスト。各オブジェクトは、レジストリ内のモジュールのメンテナーの情報に対応しています。これは、プロジェクトの作成者と同じである必要はありません。
  - versions: このレジストリで見つかったこのモジュールのすべてのバージョンのリスト
  - yanked_versions: このモジュールの削除されたバージョンのマップ。キーはヤンクするバージョンで、値はバージョンがヤンクされる理由の説明です。理想的には、詳細情報へのリンクを含める必要があります。
/modules/$MODULE/$VERSION: 次のファイルを含むディレクトリ:
- MODULE.bazel: このモジュールバージョンの MODULE.bazel ファイル
- source.json: このモジュールバージョンのソースを取得する方法に関する情報を含む JSON ファイル
  - デフォルトのタイプは「archive」で、http_archive リポジトリを表します。次のフィールドがあります。
    - url: ソースアーカイブの URL
    - integrity: アーカイブの Subresource Integrity チェックサム
    - strip_prefix: ソースアーカイブを抽出するときに削除するディレクトリ接頭辞
    - patches: 抽出されたアーカイブに適用するパッチファイルを含むマップ。パッチファイルは /modules/$MODULE/$VERSION/patches ディレクトリにあります。キーはパッチファイル名で、値はパッチファイルの完全性チェックサムです。
    - patch_strip: Unix patch の --strip 引数と同じ。
    - archive_type: ダウンロードしたファイルのアーカイブタイプ（http_archive の type と同じ）。デフォルトでは、アーカイブタイプは URL のファイル拡張子から決定されます。ファイルに拡張子がない場合は、"zip"、"jar"、"war"、"aar"、"tar"、"tar.gz"、"tgz"、"tar.xz"、"txz"、"tar.zst"、"tzst"、tar.bz2、"ar"、"deb" のいずれかを明示的に指定できます。
  - 次のフィールドを使用して、git リポジトリを使用するようにタイプを変更できます。
    - type: git_repository
    - https://bazel.build/rules/lib/repo/git で説明されている次のフィールド。
      - remote
      - commit
      - shallow_since
      - tag
      - init_submodules
      - verbose
      - strip_prefix
  - 型は、次のフィールドを使用して local_repository リポジトリを表すローカルパスを使用するように変更できます。
    - type: local_path
    - path: リポジトリのローカルパス。次のように計算されます。
      - path が絶対パスの場合、そのままになります。
      - path が相対パスで、module_base_path が絶対パスの場合、<module_base_path>/<path> に解決されます。
      - path と module_base_path の両方が相対パスの場合、<registry_path>/<module_base_path>/<path> に解決されます。レジストリはローカルでホストされ、--registry=file://<registry_path> で使用される必要があります。それ以外の場合は、Bazel がエラーをスローします。
- patches/: パッチファイルを含むオプションのディレクトリ。source.json のタイプが「archive」の場合にのみ使用されます。

`metadata.json`

metadata.json は、モジュールに関する情報を含むオプションの JSON ファイルです。次のフィールドがあります。

versions: 文字列の配列。各文字列は、このレジストリで使用可能なモジュールのバージョンを示します。この配列は、モジュールディレクトリの子と一致する必要があります。
yanked_versions: このモジュールの削除されたバージョンを指定する JSON オブジェクト。キーはヤンクするバージョンで、値はバージョンがヤンクされる理由の説明です。理想的には、詳細情報へのリンクを含めるべきです。

BCR では、metadata.json ファイルにさらに多くの情報が必要になります。

`source.json`

source.json は、モジュールの特定のバージョンを取得する方法に関する情報を含む必須の JSON ファイルです。このファイルのスキーマは type フィールドによって異なります。デフォルトは archive です。

type が archive（デフォルト）の場合、このモジュールバージョンは http_archive repo ルールによってバックアップされます。このモジュールバージョンは、指定された URL からアーカイブをダウンロードしてそのコンテンツを抽出することで取得されます。次のフィールドがサポートされています。
- url: 文字列。ソースアーカイブの URL
- mirror_urls: 文字列のリスト。ソースアーカイブのミラー URL。URL は url の後にバックアップとして順番に試行されます。
- integrity: 文字列。アーカイブの [Subresource Integrity][subresource-integrity] チェックサム
- strip_prefix: ソースアーカイブを抽出するときに削除するディレクトリ接頭辞の文字列
- overlay: 抽出されたアーカイブの上にレイヤリングするオーバーレイファイルを含む JSON オブジェクト。パッチファイルは /modules/$MODULE/$VERSION/overlay ディレクトリにあります。キーはオーバーレイファイル名で、値はオーバーレイファイルの完全性チェックサムです。オーバーレイはパッチファイルの前に適用されます。
- patches: 抽出されたアーカイブに適用するパッチファイルを含む JSON オブジェクト。パッチファイルは /modules/$MODULE/$VERSION/patches ディレクトリにあります。キーはパッチファイル名で、値はパッチファイルの完全性チェックサムです。パッチはオーバーレイファイルの後に適用されます。
- patch_strip: 数値。Unix patch の --strip 引数と同じです。
- archive_type: 文字列。ダウンロードしたファイルのアーカイブタイプ（http_archive の type と同じ）。
type が git_repository の場合、このモジュールバージョンは git_repository リポジトリルールによってバックアップされます。Git リポジトリのクローンを作成して取得します。
- 次のフィールドがサポートされており、基盤となる git_repository repo ルールに直接転送されます。remote、commit、shallow_since、tag、init_submodules、verbose、strip_prefix。
type が local_path の場合、このモジュールバージョンは local_repository repo ルールによってバックアップされ、ローカルディスク上のディレクトリにシンボリックリンクされています。次のフィールドがサポートされています。
- path: リポジトリのローカルパス。次のように計算されます。
  - path が絶対パスの場合、そのままになります。
  - path が相対パスで、module_base_path が絶対パスの場合、<module_base_path>/<path> に解決されます。
  - path と module_base_path の両方が相対パスの場合、<registry_path>/<module_base_path>/<path> に解決されます。レジストリはローカルでホストされ、--registry=file://<registry_path> で使用される必要があります。それ以外の場合は、Bazel がエラーをスローします。

Bazel 中央レジストリ

https://bcr.bazel.build/ の Bazel Central Registry（BCR）は、GitHub リポジトリ bazelbuild/bazel-central-registry によってバックアップされたコンテンツを含むインデックスレジストリです。コンテンツは、ウェブフロントエンド（https://registry.bazel.build/）を使用して閲覧できます。

BCR は Bazel コミュニティによって管理されており、投稿者はプルリクエストを送信できます。BCR 投稿ガイドラインをご覧ください。

通常のインデックスレジストリの形式に従うことに加えて、BCR では各モジュールバージョン（/modules/$MODULE/$VERSION/presubmit.yml）の presubmit.yml ファイルが必要です。このファイルでは、このモジュールバージョンの有効性を確認するために使用できる、いくつかの重要なビルドターゲットとテストターゲットを指定します。BCR の CI パイプラインでも、モジュール間の相互運用性を確保するためにこれを使用します。

レジストリの選択

繰り返し可能な Bazel フラグ --registry を使用して、モジュールをリクエストするレジストリのリストを指定できます。これにより、サードパーティまたは内部レジストリから依存関係を取得するようにプロジェクトを設定できます。以前の登録が優先されます。便宜上、--registry フラグのリストをプロジェクトの .bazelrc ファイルに配置できます。

レジストリが GitHub でホストされている場合（たとえば、bazelbuild/bazel-central-registry のフォークとして）、--registry 値には raw.githubusercontent.com の下の GitHub の未加工のアドレスが必要です。たとえば、my-org フォークの main ブランチでは、--registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/ を設定します。

--registry フラグを使用すると、Bazel Central Registry がデフォルトで使用されなくなりますが、--registry=https://bcr.bazel.build を追加することで元に戻すことができます。

Bazel レジストリ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

インデックス レジストリ

metadata.json

source.json