Bzlmod 移行ガイド

<ph type="x-smartling-placeholder"></ph> 問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

これは、インフラストラクチャの WORKSPACE、Bzlmod は 以前の WORKSPACE システムを今後の Bazel リリースで置き換える必要があります。このガイドでは、 プロジェクトを Bzlmod に移行し、外部 IP アドレスを取得するための WORKSPACE をドロップします。 確認します。

WORKSPACE と Bzlmod の比較

Bazel の WORKSPACE と Bzlmod は、構文が異なる同様の機能を備えています。この セクションでは、特定の WORKSPACE 機能から Bzlmod。

Bazel ワークスペースのルートを定義する

WORKSPACE ファイルは、この役割のために Bazel プロジェクトのソースルートをマークします。 Bazel バージョン 6.3 以降では、MODULE.bazel に置き換えられます。Bazel バージョンを使用する 6.3 より前のバージョンでは、WORKSPACE または WORKSPACE.bazel ファイルが 作成する必要があります。

• Google Workspace

  # This file marks the root of the Bazel workspace.
  # See MODULE.bazel for external dependencies setup.
  

bazelrc で Bzlmod を有効にする

.bazelrc を使用すると、Bazel を実行するたびに適用されるフラグを設定できます。有効にするには Bzlmod。--enable_bzlmod フラグを使用して common コマンドに適用します。 すべてのコマンドに適用されます。

• .bazelrc

  # Enable Bzlmod for every Bazel command
  common --enable_bzlmod
  

ワークスペースのリポジトリ名を指定します

• Google Workspace

  workspace 関数が使用されている ワークスペースのリポジトリ名を指定します。これにより @<workspace name>//foo:bar として参照されるワークスペース内の //foo:bar。指定しない場合、デフォルトのリポジトリ名 ワークスペースは __main__ です。

  ## WORKSPACE
  workspace(name = "com_foo_bar")
  

• Bzlmod

  同じワークスペース内でターゲットを参照する場合は、 @<repo name> のない //foo:bar 構文。しかし、古い構文が必要であれば、 使用する場合は、モジュール名を使用して module 関数をリポジトリとして機能させる 表示されます。モジュール名が必要なリポジトリ名と異なる場合は、 次の属性の repo_name 属性を使用できます: module 関数を呼び出して、 リポジトリ名。

  ## MODULE.bazel
  module(
      name = "bar",
      repo_name = "com_foo_bar",
  )
  

外部依存関係を Bazel モジュールとして取得する

依存関係が Bazel プロジェクトの場合は、 Bazel モジュールも Bzlmod を採用している場合。

• Google Workspace

  WORKSPACE では、 http_archive または git_repository リポジトリ ルールを Bazel プロジェクトのソースをダウンロードします。

  ## WORKSPACE
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
  
  http_archive(
      name = "bazel_skylib",
      urls = ["https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz"],
      sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa",
  )
  load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
  bazel_skylib_workspace()
  
  http_archive(
      name = "rules_java",
      urls = ["https://github.com/bazelbuild/rules_java/releases/download/6.1.1/rules_java-6.1.1.tar.gz"],
      sha256 = "76402a50ae6859d50bd7aed8c1b8ef09dae5c1035bb3ca7d276f7f3ce659818a",
  )
  load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains")
  rules_java_dependencies()
  rules_java_toolchains()
  

  ご覧のとおり、これは一般的なパターンとして、ユーザーが マクロから依存関係を認識します。bazel_skylib と rules_java は、platform の正確なバージョンである platform に依存しています。 マクロの順序によって決まります。

• Bzlmod

  Bzlmod では、依存関係が Bazel Central で利用可能である限り レジストリまたはカスタム Bazel レジストリに依存し、 bazel_dep ディレクティブ。

  ## MODULE.bazel
  bazel_dep(name = "bazel_skylib", version = "1.4.2")
  bazel_dep(name = "rules_java", version = "6.1.1")
  

  bzlmod は、 MVS アルゴリズム。したがって、最大値は 必要なバージョンの platform が自動的に選択されます。

依存関係を Bazel モジュールとしてオーバーライドする

ルート モジュールとして、さまざまな構成で Bazel モジュールの依存関係をオーバーライドできます。 できます。

詳しくは、オーバーライドのセクションをご覧ください。 情報です。

使用例については、 例 できます。

モジュール拡張機能を使用して外部依存関係を取得する

依存関係が Bazel プロジェクトでない場合、またはどの Bazel でも使用できない場合 できます。GKE の use_repo_rule またはモジュール 拡張機能をご覧ください。

• Google Workspace

  http_file を使用してファイルをダウンロードする リポジトリ ルールを使用します。

  ## WORKSPACE
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
  
  http_file(
      name = "data_file",
      url = "http://example.com/file",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )
  

• Bzlmod

  Bzlmod では、MODULE.bazel で use_repo_rule ディレクティブを使用できます。 ファイルを使用して、リポジトリを直接インスタンス化できます。

  ## MODULE.bazel
  http_file = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
  http_file(
      name = "data_file",
      url = "http://example.com/file",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )
  

  内部では、これはモジュール拡張機能を使用して実装されています。必要に応じて 単にリポジトリ ルールを呼び出すよりも複雑なロジックを実行する場合は、 モジュール拡張機能をご自身で実装できます。定義を移動する必要があります。 .bzl ファイルにまとめます。これにより、定義を共有することもできます。 移行期間中の WORKSPACE と Bzlmod。

  ## repositories.bzl
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
  def my_data_dependency():
      http_file(
          name = "data_file",
          url = "http://example.com/file",
          sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      )
  

  依存関係マクロを読み込むモジュール拡張機能を実装します。1 対 1 の マクロの同じ .bzl ファイル内で指定しますが、互換性を維持するため 古い Bazel バージョンがある場合は、別の .bzl ファイルで定義することをおすすめします。

  ## extensions.bzl
  load("//:repositories.bzl", "my_data_dependency")
  def _non_module_dependencies_impl(_ctx):
      my_data_dependency()
  
  non_module_dependencies = module_extension(
      implementation = _non_module_dependencies_impl,
  )
  

  リポジトリをルート プロジェクトから参照できるようにするには、 モジュール拡張子と MODULE.bazel ファイル内のリポジトリの使用。

  ## MODULE.bazel
  non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies")
  use_repo(non_module_dependencies, "data_file")
  

モジュール拡張との外部依存関係の競合を解決する

プロジェクトでは、ソースコードに基づいて外部リポジトリを導入するマクロを 呼び出すことができます。しかし、同じセッション内に複数の呼び出し元が 競合を引き起こすのでしょうか。

プロジェクト foo が、version を受け取る次のマクロを提供しているとします。 渡します。

## repositories.bzl in foo {:#repositories.bzl-foo}
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def data_deps(version = "1.0"):
    http_file(
        name = "data_file",
        url = "http://example.com/file-%s" % version,
        # Omitting the "sha256" attribute for simplicity
    )

• Google Workspace

  WORKSPACE では、@foo からマクロを読み込み、バージョンを指定できます。 必要なデータ依存関係を選択できます。別の依存関係 @bar があるとします。 @foo にも依存しますが、異なるバージョンのデータが必要です。 学びます。

  ## WORKSPACE
  
  # Introduce @foo and @bar.
  ...
  
  load("@foo//:repositories.bzl", "data_deps")
  data_deps(version = "2.0")
  
  load("@bar//:repositories.bzl", "bar_deps")
  bar_deps() # -> which calls data_deps(version = "3.0")
  

  この場合、エンドユーザーは、 ワークスペースで必要なバージョンを入手できます。これはクラウドにおける WORKSPACE では、移行のための合理的な手段が 解決できます。

• Bzlmod

  Bzlmod では、プロジェクト foo の作成者がモジュール拡張機能を使用して問題を解決できます。 重複します。たとえば、スペース名詞を常に選択することが すべての Bazel モジュールの中で、データ依存関係に必要な最大バージョン。

  ## extensions.bzl in foo
  load("//:repositories.bzl", "data_deps")
  
  data = tag_class(attrs={"version": attr.string()})
  
  def _data_deps_extension_impl(module_ctx):
      # Select the maximal required version in the dependency graph.
      version = "1.0"
      for mod in module_ctx.modules:
          for data in mod.tags.data:
              version = max(version, data.version)
      data_deps(version)
  
  data_deps_extension = module_extension(
      implementation = _data_deps_extension_impl,
      tag_classes = {"data": data},
  )
  

  ## MODULE.bazel in bar
  bazel_dep(name = "foo", version = "1.0")
  
  foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
  foo_data_deps.data(version = "3.0")
  use_repo(foo_data_deps, "data_file")
  

  ## MODULE.bazel in root module
  bazel_dep(name = "foo", version = "1.0")
  bazel_dep(name = "bar", version = "1.0")
  
  foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
  foo_data_deps.data(version = "2.0")
  use_repo(foo_data_deps, "data_file")
  

  この場合、ルート モジュールにはデータ バージョン 2.0 が必要ですが、 依存関係 bar には 3.0 が必要です。foo のモジュール拡張機能は、 この競合を解決し、データにはバージョン 3.0 が自動的に選択されます 学びます。

サードパーティのパッケージ管理システムを統合する

前のセクションのとおり、モジュール拡張によって カスタム ロジックを実行して問題を解決し、 リポジトリ ルールを呼び出して外部リポジトリを導入することで、 統合するルールセットをルール作成者が強化できる パッケージ管理システムもサポートしています。

詳しくは、モジュール拡張機能のページをご覧ください。 詳しく学びます。

依存関係を取得するためにすでに Bzlmod を採用しているルールセットのリスト 出力する方法です。

• rules_jvm_external
• rules_go
• rules_python

疑似パッケージ管理システムを統合する最小限のサンプルは、 例 できます。

ホストマシン上のツールチェーンを検出する

ホストで利用可能なツールチェーンを Bazel ビルドルールで検出する必要がある場合 リポジトリのルールを使用してホストマシンを検査し、 外部リポジトリとして使用します。

• Google Workspace

  次のようなリポジトリ ルールでシェル ツールチェーンを検出します。

  ## local_config_sh.bzl
  def _sh_config_rule_impl(repository_ctx):
      sh_path = get_sh_path_from_env("SH_BIN_PATH")
  
      if not sh_path:
          sh_path = detect_sh_from_path()
  
      if not sh_path:
          sh_path = "/shell/binary/not/found"
  
      repository_ctx.file("BUILD", """
  load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain")
  sh_toolchain(
      name = "local_sh",
      path = "{sh_path}",
      visibility = ["//visibility:public"],
  )
  toolchain(
      name = "local_sh_toolchain",
      toolchain = ":local_sh",
      toolchain_type = "@bazel_tools//tools/sh:toolchain_type",
  )
  """.format(sh_path = sh_path))
  
  sh_config_rule = repository_rule(
      environ = ["SH_BIN_PATH"],
      local = True,
      implementation = _sh_config_rule_impl,
  )
  

  リポジトリ ルールを WORKSPACE に読み込むことができます。

  ## WORKSPACE
  load("//:local_config_sh.bzl", "sh_config_rule")
  sh_config_rule(name = "local_config_sh")
  

• Bzlmod

  Bzlmod では、モジュール拡張機能を使用して同じリポジトリを導入できます。 これは、前回の @data_file リポジトリの導入と類似しています。 。

  ## local_config_sh_extension.bzl
  load("//:local_config_sh.bzl", "sh_config_rule")
  
  sh_config_extension = module_extension(
      implementation = lambda ctx: sh_config_rule(name = "local_config_sh"),
  )
  

  次に、MODULE.bazel ファイル内の拡張子を使用します。

  ## MODULE.bazel
  sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
  use_repo(sh_config_ext, "local_config_sh")
  

ツールチェーンの登録と実行プラットフォーム

前のセクションの続きとして、ツールチェーンをホストするリポジトリを紹介した後 情報（local_config_sh など）が存在すれば、通常は ツールチェーン。

• Google Workspace

  WORKSPACE では、次の方法でツールチェーンを登録できます。

  1. ツールチェーンを .bzl ファイルに登録して、マクロを WORKSPACE ファイル。

     ## local_config_sh.bzl
     def sh_configure():
         sh_config_rule(name = "local_config_sh")
         native.register_toolchains("@local_config_sh//:local_sh_toolchain")
     

     ## WORKSPACE
     load("//:local_config_sh.bzl", "sh_configure")
     sh_configure()
     

  2. または、ツールチェーンを WORKSPACE ファイルに直接登録します。

     ## WORKSPACE
     load("//:local_config_sh.bzl", "sh_config_rule")
     sh_config_rule(name = "local_config_sh")
     register_toolchains("@local_config_sh//:local_sh_toolchain")
     

• Bzlmod

  Bzlmod では、 register_toolchains、 register_execution_platforms API は MODULE.bazel ファイルでのみ使用できます。次の呼び出しはできません モジュール拡張機能内の native.register_toolchains。

  ## MODULE.bazel
  sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
  use_repo(sh_config_ext, "local_config_sh")
  register_toolchains("@local_config_sh//:local_sh_toolchain")
  

WORKSPACE に登録されているツールチェーンと実行プラットフォーム。 WORKSPACE.bzlmod と各 Bazel モジュールの MODULE.bazel ファイルは、次のようになります。 ツールチェーン選択時の優先順位（降順）:

1. ツールチェーンと実行プラットフォーム（ルート モジュールの MODULE.bazel ファイル。
2. WORKSPACE に登録されているツールチェーンと実行プラットフォーム、 WORKSPACE.bzlmod ファイル。
3. モジュールによって登録されたツールチェーンと実行プラットフォームが 依存関係が存在します。
4. WORKSPACE.bzlmod を使用しない場合: WORKSPACE に登録されているツールチェーン suffix です。

ローカル リポジトリを導入する

依存関係をローカル リポジトリとして導入する必要がある場合は、 デバッグのために依存関係のローカル バージョンを使用する場合や、 外部リポジトリとして公開できます

• Google Workspace

  WORKSPACE では、このことは次の 2 つのネイティブ リポジトリ ルールによって実現されます。 local_repository、 new_local_repository。

  ## WORKSPACE
  local_repository(
      name = "rules_java",
      path = "/Users/bazel_user/workspace/rules_java",
  )
  

• Bzlmod

  Bzlmod では、次を使用できます。 local_path_override～ ローカルパスでモジュールをオーバーライドできます。

  ## MODULE.bazel
  bazel_dep(name = "rules_java")
  local_path_override(
      module_name = "rules_java",
      path = "/Users/bazel_user/workspace/rules_java",
  )
  

  注: local_path_override では、ローカル ディレクトリのみを導入できます。 Bazel モジュールとして扱われるため、MODULE.bazel ファイルとそのバージョンを持つ 一時的な依存関係は、依存関係の実行時に考慮される 解決します。また、すべてのモジュール オーバーライド ディレクティブを使用できるのは、

  モジュール拡張を使用してローカル リポジトリを導入することもできます。 ただし、モジュール拡張では native.local_repository を呼び出すことはできません。 すべてのネイティブ リポジトリ ルールを明確化する取り組みが進行中です（ 進行状況は #18285 です）。 次に、対応する Stlark の local_repository をモジュール内で呼び出します。 あります。また、カスタム バージョンの Kubernetes API を ブロックの問題である場合は local_repository リポジトリ ルール。

バインド ターゲット

WORKSPACE の bind ルールは非推奨となり、 Bzlmod ではサポートされていません。これは、ターゲットにエイリアスを 特別な //external パッケージ。これに依存しているすべてのユーザーは移行する必要があります。

たとえば チェックアウトマイクロサービスを呼び出す

## WORKSPACE
bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

これにより、他のターゲットが //external:openssl に依存できるようになります。Google Cloud の 次のようにすることができます。

• //external:openssl のすべての使用を次のように置き換えます。 @my-ssl//src:openssl-lib。

• または、alias ビルドルールを使用する

  • パッケージで次のターゲットを定義します（例: //third_party）

    ## third_party/BUILD
    alias(
        name = "openssl,
        actual = "@my-ssl//src:openssl-lib",
    )
    

  • //external:openssl のすべての使用を次のように置き換えます。 //third_party:openssl-lib。

移行

このセクションでは、Bzlmod の移行に役立つ情報とガイダンスを示します。 プロセスです

WORKSPACE の依存関係を把握する

移行の最初のステップは、どのような依存関係が存在するかを把握することです。これは、 環境に導入されている正確な依存関係を把握するのが WORKSPACE ファイル（推移的依存関係は *_deps で読み込まれることが多いため） マクロ。

ワークスペースの解決済みファイルを使用して外部依存関係を検査する

幸い、このフラグは --experimental_repository_resolved_file をご覧ください。このフラグは基本的に「ロックファイル」を生成します。外部で取得されたすべてのイベントのうち 依存関係も確認できます。詳しくは、こちらのブログ 投稿をご覧ください。

次の 2 つの方法で使用できます。

1. 特定のターゲットをビルドするために必要な外部依存関係の情報を取得する。

   bazel clean --expunge
   bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
   

2. WORKSPACE ファイルで定義されたすべての外部依存関係の情報を取得します。

   bazel clean --expunge
   bazel sync --experimental_repository_resolved_file=resolved.bzl
   

   bazel sync コマンドを使用すると、 WORKSPACE ファイルには、以下が含まれます。

   • bind 使用状況
   • register_toolchains とregister_execution_platforms の使用

   ただし、プロジェクトがクロス プラットフォームの場合、特定のプラットフォームで bazel 同期が機能しないことがあります。 一部のリポジトリ ルールは、サポートされている 説明します。

このコマンドを実行すると、 resolved.bzl ファイルの依存関係。

bazel query で外部依存関係を検査する

また、bazel query を使用してリポジトリ ルールを検査することもできます。

bazel query --output=build //external:<repo name>

その方が便利で高速だが、bazel クエリは 外部依存関係のバージョン、 使用する際はご注意ください。外部へのクエリと検査 Bzlmod による依存関係は、新しいソリューションによって サブコマンドを実行します。

組み込みのデフォルトの依存関係

--experimental_repository_resolved_file によって生成されたファイルを確認すると、 WORKSPACE に定義されていない多くの依存関係が見つかるでしょう。 これは、Bazel がユーザーの WORKSPACE に接頭辞と接尾辞を追加するためです。 ファイル コンテンツを使用して、デフォルトの依存関係を注入します。これは通常、 （例: @bazel_tools、@platforms、@remote_java_tools）。あり Bzlmod など、これらの依存関係は組み込みモジュールによって bazel_tools（他のすべてのコンポーネントに対するデフォルトの依存関係） Bazel モジュールです。

ハイブリッド モードによる段階的な移行

Bzlmod と WORKSPACE は併用できるため、依存関係の移行が可能 段階的に移行する必要があります。

WORKSPACE.bzlmod

Bazel ユーザーは移行中に、 と のビルドを切り替える必要が生じる場合があります。 Bzlmod が有効になっていない場合。WORKSPACE.bzlmod のサポートが実装され、 プロセスがよりスムーズになります

WORKSPACE.bzlmod の構文は WORKSPACE とまったく同じです。Bzlmod が有効な場合 WORKSPACE.bzlmod ファイルもワークスペースのルートに存在する場合は、次のようになります。

• WORKSPACE.bzlmod が有効になり、WORKSPACE の内容は無視されます。
• プレフィックスやサフィックスが WORKSPACE.bzlmod ファイルに追加されます。

WORKSPACE.bzlmod ファイルを使用すると、次の理由で移行が簡単になります。

• Bzlmod が無効になっている場合は、代わりに コピーします。
• Bzlmod を有効にすると、どのような依存関係が残っているかをより正確に追跡できます WORKSPACE.bzlmod を使用して移行します。

で確認できます。

注: WORKSPACE.bzlmod は、Google Workspace for Education の ワークスペースのルートを識別できません。したがって、 移動します。

リポジトリの公開設定

bzlmod は、特定のリポジトリから参照できる他のリポジトリを制御できます。 リポジトリの名前と厳格な値を確認し、 を参照してください。

さまざまなタイプのリポジトリの公開設定の概要を以下に示します。 リポジトリも参照してください。

	メイン リポジトリから	Bazel モジュール リポジトリから	モジュール拡張機能リポジトリから	WORKSPACE リポジトリから
メイン リポジトリ	表示	ルート モジュールが直接依存関係の場合	ルート モジュールが、モジュール拡張機能をホストするモジュールに直接依存している場合	表示
Bazel モジュール リポジトリ	直接依存関係	直接依存関係	モジュール拡張機能をホストするモジュールの直接の依存関係	ルート モジュールの直接依存関係
モジュール拡張リポジトリ	直接依存関係	直接依存関係	モジュール拡張機能をホストするモジュールの直接の依存関係 + 同じモジュール拡張機能によって生成されたすべてのリポジトリ	ルート モジュールの直接依存関係
WORKSPACE リポジトリ	表示可能なすべて	非表示	非表示	表示可能なすべて

注: ルート モジュールでは、リポジトリ @foo が WORKSPACE で定義され、 @foo は見かけのリポジトリとしても使用される 名前（MODULE.bazel）の場合は @foo、 MODULE.bazel で導入されたものを指します。

注: モジュール拡張機能で生成されたリポジトリ @bar で、@foo が 明らかなリポジトリ名: 生成され、別のリポジトリに直接接続し、 モジュール拡張機能をホストするモジュールの依存関係を @bar、@foo は後者を指します。

移行プロセス

一般的な Bzlmod 移行プロセスは次のようになります。

1. WORKSPACE にどのような依存関係があるかを把握します。
2. プロジェクトのルートに空の MODULE.bazel ファイルを追加します。
3. 空の WORKSPACE.bzlmod ファイルを追加して、WORKSPACE ファイルの内容をオーバーライドします。
4. Bzlmod を有効にしてターゲットをビルドし、どのリポジトリが使用されているかを確認する ありません。
5. 解決された依存関係で欠落しているリポジトリの定義を確認する 表示されます。
6. モジュールを使用して、不足している依存関係を Bazel モジュールとして導入する 後で移行するために WORKSPACE.bzlmod に残すこともできます。
7. 手順 4 に戻って、すべての依存関係が使用可能になるまで繰り返します。

移行ツール

インタラクティブな Bzlmod 移行ヘルパー スクリプトがあります。 を始めましょう。

このスクリプトは次の処理を行います。

• WORKSPACE の解決済みファイルを生成して解析します。
• 解決済みファイルのリポジトリ情報を人が読める形式で出力します。
• bazel ビルドコマンドを実行して、認識されたエラー メッセージを検出して、 移行する方法だと考えてください。
• BCR で依存関係がすでに使用可能かどうかを確認します。
• MODULE.bazel ファイルに依存関係を追加します。
• モジュール拡張機能を使用して依存関係を追加します。
• WORKSPACE.bzlmod ファイルに依存関係を追加する。

Bazel を使用するには、最新の Bazel リリースがインストールされていることを確認し、 次のコマンドを実行します。

git clone https://github.com/bazelbuild/bazel-central-registry.git
cd <your workspace root>
<BCR repo root>/tools/migrate_to_bzlmod.py -t <your build targets>

注: この移行スクリプトは完全ではなく、Bzlmod により最新ではない可能性があります。 常に進化しているので、推奨されるソリューションが適切なものであるか常に再確認してください。

Bazel モジュールを公開する

Bazel プロジェクトが他のプロジェクトの依存関係の場合は、 Bazel Central Registry で確認できます。

BCR でプロジェクトをチェックインできるようにするには、次のソース アーカイブ URL が必要です。 できます。ソース アーカイブを作成する際は、以下の点に注意してください。

• アーカイブが特定のバージョンを指していることを確認します。

  BCR はバージョニングされたソース アーカイブのみを受け入れます。これは、Bzlmod ではバージョン管理されたソース アーカイブのみが 依存関係の解決中にバージョンの比較を行う。

• アーカイブ URL が安定していることを確認します。

  Bazel はハッシュ値でアーカイブの内容を検証するため、 ダウンロードしたファイルのチェックサムが変わらないことを確認してください。URL が リリースページでリリース アーカイブを作成してアップロードしてください。 GitHub は、GitHub で生成されたソース アーカイブのチェックサムを保証しません。 提供しますつまり、URL は https://github.com/<org>/<repo>/releases/download/... は安定しているとみなされます https://github.com/<org>/<repo>/archive/... はそうではありません。GitHub アーカイブ チェックサム サービス停止 を参照してください。

• ソースツリーが元のリポジトリのレイアウトに従っていることを確認します。

  リポジトリが非常に大きく、ディストリビューション アーカイブのサイズを小さくして不要なソースを削除して、 取り除かれたソースツリーが元のソースツリーのサブセットであることを確認します。この を使用すると、エンドユーザーがモジュールを非リリース バージョンに簡単にオーバーライドできるようになります。 バージョン: archive_override および git_override。

• 最も一般的なものをテストするテスト モジュールをサブディレクトリに含めます。 API。

  テスト モジュールは、独自の WORKSPACE と MODULE.bazel を持つ Bazel プロジェクトです ファイルがソース アーカイブのサブディレクトリ 実際のモジュールを公開します。これにはいくつかの例を含める必要がある 一般的な API をカバーする統合テストを行えます。確認 テスト モジュールをご覧ください。

ソース アーカイブ URL の準備ができたら、BCR の協力依頼書に沿ってください ガイドラインに沿ってモジュールを GitHub で BCR に送信 pull リクエスト。

[公開先 BCR GitHub アプリ リポジトリを使用して、モジュールを BCR に送信するプロセスを自動化できます。

ベスト プラクティス

このセクションでは、品質向上のために従うべきベスト プラクティスをいくつか紹介します。 外部依存関係の管理に使用できます。

不要な依存関係を取得しないように、ターゲットを別々のパッケージに分割します。

#12835 を確認します。dev は ビルドするために、テストの依存関係が不必要に取得されてしまう 不要になるかもしれませんこれは実際には Bzlmod 固有ではありませんが、 これにより、開発環境の依存関係を正しく指定しやすくなります。

開発環境の依存関係を指定する

この場合、dev_dependency 属性を true に設定できます。 bazel_dep および use_extension ディレクティブを使用して、 依存するプロジェクトには反映されません。ルート モジュールとして、Python 図の --ignore_dev_dependency フラグ: ターゲットが 開発の依存関係がなくてもビルドできます。

コミュニティの移行の進行状況

Bazel Central Registry で、 依存関係がすでに利用可能かどうかを 確認しますご興味がありましたら、 GitHub のディスカッションに参加し、 移行をブロックしている依存関係に賛成票を投じるか投稿します。

問題を報告する

既知の Bzlmod については、Bazel GitHub 問題リストで確認してください サポートします。新しい問題や機能リクエストを提出して、ブロックの解除にお役立てください お見せしましょう。