WORKSPACE での依存関係のシェーディング
可能な限り、プロジェクトに単一のバージョン ポリシーを設定します。これは、コンパイル対象の依存関係で最終バイナリに含まれる必要があるためです。その他のケースでは、依存関係をシャドーできます。
myproject/WORKSPACE
workspace(name = "myproject")
local_repository(
name = "A",
path = "../A",
)
local_repository(
name = "B",
path = "../B",
)
A/ワークスペース
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(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 のブートストラップ テストで行うように)。