WORKSPACE の欠点により、Bzlmod は今後の Bazel リリースで以前の WORKSPACE システムを置き換える予定です。このガイドでは、プロジェクトを Bzlmod に移行し、外部依存関係を取得するための WORKSPACE を削除する方法について説明します。
WORKSPACE と Bzlmod の比較
Bazel の WORKSPACE と Bzlmod は、構文が異なる同様の機能を備えています。このセクションでは、特定の WORKSPACE 機能から Bzlmod に移行する方法について説明します。
Bazel ワークスペースのルートを定義する
WORKSPACE ファイルは、Bazel プロジェクトのソースルートをマークします。この役割は、Bazel バージョン 6.3 以降では MODULE.bazel に置き換えられています。6.3 より前の Bazel バージョンでも、ワークスペースのルートに 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
関数は、ワークスペースのリポジトリ名を指定するために使用されます。これにより、ワークスペース内のターゲット//foo:bar
を@<workspace name>//foo:bar
として参照できます。指定しない場合、ワークスペースのデフォルトのリポジトリ名は__main__
です。## WORKSPACE workspace(name = "com_foo_bar")
Bzlmod
同じワークスペース内のターゲットは、
@<repo name>
なしの//foo:bar
構文を使用して参照することをおすすめします。ただし、古い構文が必要な場合は、module
関数で指定されたモジュール名をリポジトリ名として使用できます。モジュール名が必要なリポジトリ名と異なる場合は、module
関数のrepo_name
属性を使用してリポジトリ名をオーバーライドできます。## MODULE.bazel module( name = "bar", repo_name = "com_foo_bar", )
外部依存関係を Bazel モジュールとして取得する
依存関係が Bazel プロジェクトである場合、Bazel モジュールで Bzlmod も導入されていれば、Bazel モジュールとして信頼できるはずです。
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 Registry またはカスタム 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 アルゴリズムを使用して Bazel モジュールの依存関係を推移的に解決します。したがって、必要な最大バージョンの
platform
が自動的に選択されます。
依存関係を Bazel モジュールとしてオーバーライドする
ルート モジュールは、Bazel モジュールの依存関係をさまざまな方法でオーバーライドできます。
詳しくは、overridesのセクションをご覧ください。
使用例については、examples リポジトリをご覧ください。
モジュール拡張機能を使用して外部依存関係を取得する
依存関係が Bazel プロジェクトでない場合、またはどの Bazel レジストリでも使用できない場合は、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", )
依存関係マクロを読み込むモジュール拡張機能を実装します。マクロの同じ
.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 内のマクロの順序を慎重に調整する必要があります。これは、依存関係を解決する有効な方法を提供できないため、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 を採用しているルールセットのリストを以下に示します。
疑似パッケージ管理システムを統合する最小限のサンプルは、examples リポジトリにあります。
ホストマシン上のツールチェーンを検出する
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
API と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
サフィックスに登録されているツールチェーン。
ローカル リポジトリを導入する
デバッグのために依存関係のローカル バージョンが必要な場合や、外部リポジトリとしてワークスペースにディレクトリを組み込む場合は、依存関係をローカル リポジトリとして導入することが必要な場合があります。
Google Workspace
WORKSPACE では、これは
local_repository
とnew_local_repository
の 2 つのネイティブ リポジトリ ルールによって実現されます。## 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 を確認してください)。次に、対応する Stlark のlocal_repository
をモジュール拡張機能で呼び出すことができます。これがブロック的な問題である場合、local_repository
リポジトリ ルールのカスタム バージョンの実装も簡単です。
バインド ターゲット
WORKSPACE の bind
ルールは非推奨であり、Bzlmod ではサポートされていません。これは、特別な //external
パッケージでターゲットにエイリアスを与えるために導入されました。これに依存しているすべてのユーザーは移行する必要があります。
たとえば チェックアウトマイクロサービスを呼び出す
## WORKSPACE
bind(
name = "openssl",
actual = "@my-ssl//src:openssl-lib",
)
これにより、他のターゲットが //external:openssl
に依存できるようになります。次の方法で移行できます。
//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 コマンドは使用できなくなりましたが、fetch にはさまざまなオプションが用意されています。ターゲット、リポジトリ、構成された一連のリポジトリ、または依存関係の解決とモジュール拡張に関連するすべてのリポジトリをフェッチできます。取得結果はキャッシュに保存されます。強制的に取得するには、取得プロセス中に
--force
オプションを含める必要があります。
移行
このセクションでは、Bzlmod の移行プロセスに役立つ情報とガイダンスについて説明します。
WORKSPACE の依存関係を把握する
移行の最初のステップは、どのような依存関係が存在するかを把握することです。一時的な依存関係は *_deps
マクロで読み込まれることが多いため、WORKSPACE ファイルに導入された正確な依存関係を把握するのが難しい場合があります。
ワークスペースの解決済みファイルを使用して外部依存関係を検査する
この場合、--experimental_repository_resolved_file
フラグを使用すると便利です。このフラグは基本的に、最後の Bazel コマンドで取得したすべての外部依存関係の「ロックファイル」を生成します。詳しくは、こちらのブログ投稿をご覧ください。
次の 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 に依存関係を段階的に移行できます。
WORKSPACE.bzlmod
Bazel ユーザーは、移行中、Bzlmod が有効な場合と無効なビルドを切り替える必要があります。プロセスをスムーズにするために、WORKSPACE.bzlmod のサポートが実装されています。
WORKSPACE.bzlmod の構文は WORKSPACE とまったく同じです。Bzlmod が有効になっている場合、ワークスペースのルートに WORKSPACE.bzlmod ファイルも存在する場合は次のようになります。
WORKSPACE.bzlmod
が有効になり、WORKSPACE
の内容は無視されます。- WORKSPACE.bzlmod ファイルにプレフィックスやサフィックスは追加されません。
WORKSPACE.bzlmod ファイルを使用すると、次の理由で移行が簡単になります。
- Bzlmod が無効になっている場合は、元の WORKSPACE ファイルから依存関係の取得にフォールバックします。
- Bzlmod を有効にすると、WORKSPACE.bzlmod を使用して、移行する必要がある依存関係をより正確に追跡できます。
リポジトリの公開設定
Bzlmod は、特定のリポジトリから他のどのリポジトリを公開するかを制御できます。詳細については、リポジトリ名と厳格な依存関係をご覧ください。
ここでは、WORKSPACE も考慮した場合の、さまざまなタイプのリポジトリにおけるリポジトリの公開設定の概要を示します。
メイン リポジトリから | Bazel モジュール リポジトリから | モジュール拡張機能リポジトリから | WORKSPACE リポジトリから | |
---|---|---|---|---|
メイン リポジトリ | 表示 | ルート モジュールが直接依存関係の場合 | ルート モジュールが、モジュール拡張機能をホストするモジュールに直接依存している場合 | 表示 |
Bazel モジュール リポジトリ | 直接依存関係 | 直接依存関係 | モジュール拡張機能をホストするモジュールの直接の依存関係 | ルート モジュールの直接依存関係 |
モジュール拡張リポジトリ | 直接依存関係 | 直接依存関係 | モジュール拡張機能をホストするモジュールの直接の依存関係 + 同じモジュール拡張機能によって生成されたすべてのリポジトリ | ルート モジュールの直接依存関係 |
WORKSPACE リポジトリ | 表示可能なすべて | 表示されません | 表示されません | 表示可能なすべて |
@foo
@bar
移行プロセス
一般的な Bzlmod 移行プロセスは次のようになります。
- WORKSPACE にどのような依存関係があるかを把握します。
- プロジェクトのルートに空の MODULE.bazel ファイルを追加します。
- 空の WORKSPACE.bzlmod ファイルを追加して、WORKSPACE ファイルの内容をオーバーライドします。
- Bzlmod を有効にしてターゲットをビルドし、欠落しているリポジトリを確認します。
- 解決された依存関係ファイルで、欠落しているリポジトリの定義を確認します。
- 欠落している依存関係を Bazel モジュールとして導入するか、モジュール拡張機能を使用して導入するか、後で移行するために WORKSPACE.bzlmod に残します。
- 手順 4 に戻って、すべての依存関係が使用可能になるまで繰り返します。
移行ツール
開始時には、インタラクティブな Bzlmod 移行ヘルパー スクリプトを使用できます。
このスクリプトは次の処理を行います。
- WORKSPACE の解決済みファイルを生成して解析します。
- 解決済みファイルのリポジトリ情報を人が読める形式で出力します。
- bazel ビルドコマンドを実行し、認識されたエラー メッセージを検出して、移行方法を推奨します。
- BCR で依存関係がすでに使用可能かどうかを確認します。
- MODULE.bazel ファイルに依存関係を追加します。
- モジュール拡張機能を使用して依存関係を追加します。
- WORKSPACE.bzlmod ファイルに依存関係を追加する。
これを使用するには、最新の 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 が必要です。ソース アーカイブを作成する際は、以下の点に注意してください。
アーカイブが特定のバージョンを指していることを確認します。
Bzlmod では依存関係の解決中にバージョンの比較を行う必要があるため、BCR はバージョニングされたソース アーカイブのみを受け入れます。
アーカイブ URL が安定していることを確認します。
Bazel は、ハッシュ値でアーカイブの内容を検証するため、ダウンロードしたファイルのチェックサムが変更されないようにする必要があります。URL が GitHub からのものである場合は、リリースページでリリース アーカイブを作成してアップロードしてください。GitHub は、オンデマンドで生成されるソース アーカイブのチェックサムを保証しません。つまり、
https://github.com/<org>/<repo>/releases/download/...
形式の URL は安定版と見なされますが、https://github.com/<org>/<repo>/archive/...
は安定版ではありません。詳細については、GitHub Archive Checksum のサービス停止をご覧ください。ソースツリーが元のリポジトリのレイアウトに従っていることを確認します。
リポジトリが非常に大きく、不要なソースを削除してサイズを縮小した配布アーカイブを作成する場合は、削除したソースツリーが元のソースツリーのサブセットであることを確認してください。これにより、エンドユーザーが
archive_override
とgit_override
によってモジュールを非リリース バージョンに簡単にオーバーライドできるようになります。最も一般的な API をテストするテスト モジュールをサブディレクトリに追加します。
テスト モジュールは、公開する実際のモジュールに依存するソース アーカイブのサブディレクトリにある独自の WORKSPACE ファイルと MODULE.bazel ファイルを持つ Bazel プロジェクトです。これには、最も一般的な API をカバーするサンプルまたはいくつかの統合テストが含まれている必要があります。設定方法については、テスト モジュールをご覧ください。
ソース アーカイブ URL の準備ができたら、BCR コントリビューション ガイドラインに沿って、GitHub pull リクエストとともにモジュールを BCR に送信します。
モジュールを BCR に送信するプロセスを自動化するために、リポジトリの BCR に公開 GitHub アプリを設定することを強くおすすめします。
ベスト プラクティス
このセクションでは、外部依存関係を適切に管理するためのベスト プラクティスをいくつか紹介します。
不要な依存関係を取得しないように、ターゲットを異なるパッケージに分割します。
#12835 を確認します。ここでは、テストの開発環境の依存関係が、必要のないターゲットのビルドのために不必要に取得されます。これは実際には Bzlmod 固有ではありませんが、この方法に従うと、開発の依存関係を正しく指定しやすくなります。
開発環境の依存関係を指定する
bazel_dep
ディレクティブと use_extension
ディレクティブの dev_dependency
属性を true に設定すると、依存プロジェクトには反映されません。ルート モジュールとして --ignore_dev_dependency
フラグを使用すると、ターゲットが開発環境の依存関係なしでまだビルドされているかどうかを確認できます。
コミュニティの移行の進行状況
Bazel Central Registry で、依存関係がすでに利用可能かどうかを確認できます。または、こちらの GitHub のディスカッションに参加して、移行の妨げとなっている依存関係に賛成または投稿してください。
問題を報告する
Bzlmod の既知の問題については、Bazel GitHub 問題リストをご覧ください。新しい問題や機能リクエストを提出して、移行の障害を解消してください。