このページは Cloud Translation API によって翻訳されました。

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

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

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

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

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

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