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_skylibrules_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 でも使用できない場合 レジストリに組み込まれている場合は、 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 では、次の方法でツールチェーンを登録できます。

    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_toolchainsregister_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_repositorynew_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 です)。 次に、対応する 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_toolchainsregister_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 ファイルを使用すると、次の理由で移行が簡単になります。

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

リポジトリの公開設定

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

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

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

移行プロセス

一般的な 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 リリースがインストールされていることを確認し、 次のコマンドを実行します。

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 フラグ: ターゲットが 開発の依存関係がなくてもビルドできます。

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

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

問題を報告する

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