Bazel レジストリ

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

インデックス レジストリ

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

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

  • /bazel_registry.json: レジストリのメタデータを含むオプションの JSON ファイル。
  • /modules: このレジストリ内の各モジュールのサブディレクトリを含むディレクトリ
  • /modules/$MODULE: $MODULE という名前のモジュールの各バージョンのサブディレクトリと、このモジュールのメタデータを含む metadata.json ファイルを含むディレクトリ。
  • /modules/$MODULE/$VERSION: 次のファイルを含むディレクトリ:
    • MODULE.bazel: このモジュール バージョンの MODULE.bazel ファイル。これは、Bazel の外部依存関係の解決時に読み取られる MODULE.bazel ファイルであり、ソース アーカイブのファイルではありません(非レジストリ オーバーライドがない場合)。また、このファイルを使用してリリースのバージョンを設定し、ソース アーカイブの MODULE.bazel ファイルで設定しないようにすることをおすすめします。モジュールのバージョン管理について詳しくは、よくある質問をご覧ください。
    • source.json: このモジュール バージョンのソースを取得する方法に関する情報を含む JSON ファイル
    • patches/: パッチ ファイルを含むオプションのディレクトリ。source.json のタイプが「archive」の場合にのみ使用されます。
    • overlay/: オーバーレイ ファイルを含む省略可能なディレクトリ。source.json のタイプが「archive」の場合にのみ使用されます。

bazel_registry.json

bazel_registry.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/bazhttps://example.com/mirror2/foo.com/bar/baz、最後に元のソース URL https://foo.com/bar/baz の順になります。
  • module_base_path: source.json ファイルで local_path 型のモジュールのベースパスを指定する文字列

metadata.json

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

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

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

source.json

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

  • typearchive(デフォルト)の場合、このモジュール バージョンは http_archive repo ルールによってバックアップされます。このモジュール バージョンは、指定された URL からアーカイブをダウンロードしてそのコンテンツを抽出することで取得されます。次のフィールドがサポートされています。
    • url: 文字列。ソース アーカイブの URL
    • mirror_urls: 文字列のリスト。ソース アーカイブのミラー URL。URL は url の後にバックアップとして順番に試行されます。
    • integrity: 文字列。アーカイブの Subresource Integrity チェックサム
    • strip_prefix: ソース アーカイブを抽出するときに削除するディレクトリ接頭辞の文字列
    • overlay: 抽出されたアーカイブの上にレイヤリングするオーバーレイ ファイルを含む JSON オブジェクト。パッチ ファイルは /modules/$MODULE/$VERSION/overlay ディレクトリにあります。キーはオーバーレイ ファイル名で、値はオーバーレイ ファイルの完全性チェックサムです。オーバーレイはパッチ ファイルの前に適用されます。
    • patches: 抽出されたアーカイブに適用するパッチ ファイルを含む JSON オブジェクト。パッチ ファイルは /modules/$MODULE/$VERSION/patches ディレクトリにあります。キーはパッチ ファイル名で、値はパッチ ファイルの完全性チェックサムです。パッチは、オーバーレイ ファイルの後に、patches に表示される順序で適用されます。
    • patch_strip: 数値。Unix patch--strip 引数と同じ。
    • archive_type: 文字列。ダウンロードしたファイルのアーカイブ タイプ(http_archivetype と同じ)。
  • typegit_repository の場合、このモジュール バージョンは git_repository リポジトリ ルールによってバックアップされます。Git リポジトリのクローンを作成して取得します。
    • 次のフィールドがサポートされており、基盤となる git_repository repo ルールに直接転送されます。remotecommitshallow_sincetaginit_submodulesverbosestrip_prefix
  • typelocal_path の場合、このモジュール バージョンは local_repository repo ルールによってバックアップされ、ローカル ディスク上のディレクトリにシンボリック リンクされています。次のフィールドがサポートされています。
    • path: リポジトリのローカルパス。次のように計算されます。
      • path が絶対パスの場合、そのままになります。
      • path が相対パスで、module_base_path が絶対パスの場合、<module_base_path>/<path> に解決されます。
      • pathmodule_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 を追加することで元に戻すことができます。