外部依存関係に関する高度なトピック

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

WORKSPACE での依存関係のシャドウイング

可能な限り、プロジェクトに単一のバージョン ポリシーを設定します。これは、コンパイルして最終的なバイナリに含める依存関係に必要です。その他の場合は、依存関係をシャドウイングできます。

myproject/WORKSPACE

workspace(name = "myproject")

local_repository(
    name = "A",
    path = "../A",
)
local_repository(
    name = "B",
    path = "../B",
)

A/WORKSPACE

workspace(name = "A")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "...",
)

B/WORKSPACE 

workspace(name = "B")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)

依存関係 A と B は、異なるバージョンの testrunner に依存しています。 競合することなく両方を myproject に含めるには、 myproject/WORKSPACE で異なる名前を付けます。

workspace(name = "myproject")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner-v1",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "..."
)
http_archive(
    name = "testrunner-v2",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)
local_repository(
    name = "A",
    path = "../A",
    repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
    name = "B",
    path = "../B",
    repo_mapping = {"@testrunner" : "@testrunner-v2"}
)

このメカニズムを使用して、ダイヤモンドを結合することもできます。たとえば、A と B の依存関係が同じでも名前が異なる場合は、それらの依存関係を myproject/WORKSPACEで結合します。

コマンドラインからリポジトリをオーバーライドする

コマンドラインから宣言されたリポジトリをローカル リポジトリでオーバーライドするには、 次の --override_repository フラグを使用します。このフラグを使用すると、ソースコードを変更せずに外部リポジトリの内容を変更できます。

たとえば、@foo をローカル ディレクトリ /path/to/local/foo にオーバーライドするには、 --override_repository=foo=/path/to/local/foo フラグを渡します。

次のようなユースケースがあります。

  • 問題のデバッグ。たとえば、http_archive リポジトリを、変更を簡単に行えるローカル ディレクトリにオーバーライドします。
  • ベンダリング。ネットワーク呼び出しを行うことができない環境にいる場合は、ネットワーク ベースのリポジトリ ルールをオーバーライドして、代わりにローカル ディレクトリを指すようにします。

プロキシの使用

Bazel は、HTTPS_PROXY と HTTP_PROXY 環境変数からプロキシ アドレスを取得し、これらを使用して HTTP と HTTPS ファイルをダウンロードします（ 指定されている場合）。

IPv6 のサポート

IPv6 専用マシンでは、Bazel は変更なしで依存関係をダウンロードできます。ただし、デュアルスタック IPv4/IPv6 マシンでは、Bazel は Java と同じ規則に従い、IPv4 が有効になっている場合は IPv4 を優先します。IPv4 ネットワークが外部アドレスを解決または到達できない場合など、状況によっては、Network unreachable 例外が発生してビルドが失敗することがあります。このような場合は、 Bazel の動作をオーバーライドして IPv6 を優先できます。これには、 java.net.preferIPv6Addresses=true システム プロパティを使用します。 詳細:

  • --host_jvm_args=-Djava.net.preferIPv6Addresses=true 起動 オプションを使用します。たとえば、 次の行を .bazelrc ファイルに追加します。

    startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

  • インターネットに接続する必要がある Java ビルドターゲット（統合テストなど）を実行する場合は、 --jvmopt=-Djava.net.preferIPv6Addresses=true ツール フラグを使用します。たとえば、.bazelrc ファイルに次のように記述します。

    build --jvmopt=-Djava.net.preferIPv6Addresses

  • 依存関係のバージョン解決に rules_jvm_external を使用している場合は、 -Djava.net.preferIPv6Addresses=true を COURSIER_OPTS 環境 変数に追加して、Coursier の JVM オプションを 指定します。

オフライン ビルド

飛行機での移動中など、オフラインでビルドを実行したい場合があります。このような簡単なユースケースでは、bazel fetch または bazel sync で必要なリポジトリをプリフェッチします。ビルド中にリポジトリのフェッチを無効にするには、--nofetch オプションを使用します。

必要なファイルを別のエンティティが提供する真のオフライン ビルドの場合、Bazel は --distdir オプションをサポートしています。このフラグは、リポジトリ ルールが Bazel にファイルをフェッチするように指示した場合に、そのオプションで指定されたディレクトリを最初に検索するように Bazel に指示します。ctx.downloadctx.download_and_extract必要なファイルのハッシュ値を指定すると、Bazel は最初の URL のベース名に一致するファイルを探し、ハッシュが一致する場合はローカル コピーを使用します。

Bazel 自体は、この手法を使用して、配布 アーティファクトからオフラインでブートストラップします。 これを行うには、必要なすべての外部 依存関係を内部の distdir_tarに収集します。

Bazel では、リポジトリ ルールで任意のコマンドを実行できます。ネットワークを呼び出すかどうかはわからないため、完全なオフライン ビルドを強制することはできません。ビルドがオフラインで正しく動作するかどうかをテストするには、ネットワークを手動でブロックします（ Bazel がブートストラップ テストで行うように）。