これは、インフラストラクチャの 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 を採用しているルールセットのリスト 出力する方法です。
疑似パッケージ管理システムを統合する最小限のサンプルは、 例 できます。
ホストマシン上のツールチェーンを検出する
ホストで利用可能なツールチェーンを 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 では、次の方法でツールチェーンを登録できます。
ツールチェーンを
.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()
または、ツールチェーンを 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
ファイルは、次のようになります。
ツールチェーン選択時の優先順位(降順):
- ツールチェーンと実行プラットフォーム(ルート モジュールの
MODULE.bazel
ファイル。 WORKSPACE
に登録されているツールチェーンと実行プラットフォーム、WORKSPACE.bzlmod
ファイル。- モジュールによって登録されたツールチェーンと実行プラットフォームが 依存関係が存在します。
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", )
モジュール拡張を使用してローカル リポジトリを導入することもできます。 ただし、モジュール拡張では
native.local_repository
を呼び出すことはできません。 すべてのネイティブ リポジトリ ルールを明確化する取り組みが進行中です( 進行状況は #18285 です)。 次に、モジュール内で対応する Stlarklocal_repository
を呼び出します。 あります。また、Cloud Storage バケットのカスタム バージョンを ブロックの問題である場合は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
に置き換えます。
取得と同期
Fetch コマンドと同期コマンドは、外部リポジトリをローカルにダウンロードし、
更新しました。--nofetch
を使用してオフラインでビルドできるようにする場合もあります。
フラグを指定します。
Google Workspace
同期は、すべてのリポジトリまたは特定のリポジトリに対して強制フェッチを実行します。 一方、フェッチは特定のリポジトリに対する あります。
Bzlmod
sync コマンドは使用できなくなりましたが、特典を取得する さまざまなオプションが用意されています。 ターゲット、リポジトリ、構成された一連のリポジトリ、またはすべてのリポジトリをフェッチできます 関連するリポジトリを簡単に管理できます。 取得結果はキャッシュに保存されます。強制的に取得するには、 取得プロセス中の
--force
オプション。
移行
このセクションでは、Bzlmod の移行に役立つ情報とガイダンスを示します。 プロセスです
WORKSPACE の依存関係を把握する
移行の最初のステップは、どのような依存関係が存在するかを把握することです。これは、
環境に導入されている正確な依存関係を把握するのが
WORKSPACE ファイル(推移的依存関係は *_deps
で読み込まれることが多いため)
マクロ。
ワークスペースの解決済みファイルを使用して外部依存関係を検査する
幸い、このフラグは
--experimental_repository_resolved_file
をご覧ください。このフラグは基本的に「ロックファイル」を生成します。外部で取得されたすべてのイベントのうち
依存関係も確認できます。詳しくは、こちらのブログ
投稿をご覧ください。
次の 2 つの方法で使用できます。
特定のターゲットをビルドするために必要な外部依存関係の情報を取得する。
bazel clean --expunge bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
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 を使用して移行します。
リポジトリの公開設定
bzlmod は、特定のリポジトリから参照できる他のリポジトリを制御できます。 リポジトリの名前と厳格な値を確認し、 を参照してください。
さまざまなタイプのリポジトリの公開設定の概要を以下に示します。 リポジトリも参照してください。
メイン リポジトリから | Bazel モジュール リポジトリから | モジュール拡張機能リポジトリから | WORKSPACE リポジトリから | |
---|---|---|---|---|
メイン リポジトリ | 表示 | ルート モジュールが直接依存関係の場合 | ルート モジュールが、モジュール拡張機能をホストするモジュールに直接依存している場合 | 表示 |
Bazel モジュール リポジトリ | 直接依存関係 | 直接依存関係 | モジュール拡張機能をホストするモジュールの直接の依存関係 | ルート モジュールの直接依存関係 |
モジュール拡張リポジトリ | 直接依存関係 | 直接依存関係 | モジュール拡張機能をホストするモジュールの直接の依存関係 + 同じモジュール拡張機能によって生成されたすべてのリポジトリ | ルート モジュールの直接依存関係 |
WORKSPACE リポジトリ | 表示可能なすべて | 非表示 | 非表示 | 表示可能なすべて |
移行プロセス
一般的な Bzlmod 移行プロセスは次のようになります。
- WORKSPACE にどのような依存関係があるかを把握します。
- プロジェクトのルートに空の MODULE.bazel ファイルを追加します。
- 空の WORKSPACE.bzlmod ファイルを追加して、WORKSPACE ファイルの内容をオーバーライドします。
- Bzlmod を有効にしてターゲットをビルドし、どのリポジトリが使用されているかを確認する ありません。
- 解決された依存関係で欠落しているリポジトリの定義を確認する 表示されます。
- モジュールを使用して、不足している依存関係を Bazel モジュールとして導入する 後で移行するために WORKSPACE.bzlmod に残すこともできます。
- 手順 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>
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
フラグ: ターゲットが
dev 依存関係なしでビルドできます。
コミュニティの移行の進行状況
Bazel Central Registry で、 依存関係がすでに利用可能かどうかを確かめます。ご興味がありましたら、 GitHub のディスカッションをご覧ください。 移行をブロックしている依存関係に賛成票を投じるか投稿します。
問題を報告する
既知の Bzlmod については、Bazel GitHub 問題リストで確認してください サポートします。新しい問題や機能リクエストを提出して、ブロックの解除にお役立てください お見せしましょう。