Bazel レジストリ

問題を報告する ソースを表示 Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

インデックス レジストリ

インデックス レジストリは、モジュールのリストに関する情報（ホームページ、メンテナー、各バージョンの 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/baz、https://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 です。

  • type が archive の場合（デフォルト）、このモジュール バージョンは http_archive リポジトリ ルールによってサポートされています。このモジュール バージョンは、指定された URL からアーカイブをダウンロードしてそのコンテンツを抽出することで取得されます。次のフィールドがサポートされています。
    • url: ソース アーカイブの URL を含む文字列
    • mirror_urls: ソース アーカイブのミラー URL の文字列のリスト。URL は、url の後にバックアップとして順番に試行されます。
    • integrity: 文字列。アーカイブの サブリソースの完全性チェックサム
    • strip_prefix: ソース アーカイブの抽出時に削除するディレクトリ接頭辞の文字列
    • overlay: 抽出されたアーカイブの上に重ねるオーバーレイ ファイルを含む JSON オブジェクト。パッチファイルは /modules/$MODULE/$VERSION/overlay ディレクトリにあります。キーはオーバーレイ ファイル名で、値はオーバーレイ ファイルの完全性チェックサムです。オーバーレイはパッチファイルの前に適用されます。
    • patches: 抽出されたアーカイブに適用するパッチ ファイルを含む JSON オブジェクト。パッチファイルは /modules/$MODULE/$VERSION/patches ディレクトリにあります。キーはパッチファイル名で、値はパッチファイルの完全性チェックサムです。パッチは、オーバーレイ ファイルの後に、patches に表示される順序で適用されます。
    • patch_strip: 数値。Unix patch の --strip 引数と同じです。
    • archive_type: ダウンロードしたファイルのアーカイブ タイプ（http_archive の type と同じ）。
  • type が git_repository の場合、このモジュール バージョンは git_repository リポジトリ ルールによってサポートされています。これは、Git リポジトリのクローンを作成して取得されます。
    • 次のフィールドがサポートされており、基盤となる git_repository リポジトリ ルールに直接転送されます。remote、commit、shallow_since、tag、init_submodules、verbose、strip_prefix。
  • type が local_path の場合、このモジュール バージョンは local_repository リポジトリ ルールによってバックアップされます。ローカルディスク上のディレクトリにシンボリック リンクされます。次のフィールドがサポートされています。
    • 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 Central Registry

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 を使用して、モジュールをリクエストするレジストリのリストを指定できます。これにより、サードパーティまたは内部レジストリから依存関係を取得するようにプロジェクトを設定できます。前のレジストリが優先されます。便利なように、プロジェクトの .bazelrc ファイルに --registry フラグのリストを配置できます。

レジストリが 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 を追加することで再び使用できます。