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

問題を報告するソースを表示 Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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/WORKSPACE で別の名前を指定することで、競合することなく両方を myproject に含めます。

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 ネットワークが外部アドレスを解決または到達できない場合など、状況によっては、Network unreachable 例外が発生してビルドが失敗することがあります。このような場合は、java.net.preferIPv6Addresses=true システムプロパティを使用して、Bazel の動作をオーバーライドし、IPv6 を優先できます。詳細は以下のとおりです。

--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 に ctx.download または ctx.download_and_extract を使用してファイルをフェッチするよう指示されたときに、そのオプションで指定されたディレクトリを最初に検索するように Bazel に指示します。必要なファイルのハッシュの合計を指定すると、Bazel は最初の URL のベース名に一致するファイルを検索し、ハッシュが一致する場合はローカルコピーを使用します。

Bazel 自体はこの手法を使用して、ディストリビューションアーティファクトからオフラインでブートストラップします。これは、内部 distdir_tar に必要な外部依存関係をすべて収集することで実現されます。

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