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

問題を報告 ソースを表示

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 = "..."
)

依存関係 AB はどちらも、異なるバージョンの 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"}
)

このメカニズムを使用して、ダイヤモンドを結合することもできます。たとえば、AB の依存関係が同じで、異なる名前で呼び出している場合は、それらの依存関係を 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 を使用している場合は、COURSIER_OPTS 環境変数に -Djava.net.preferIPv6Addresses=true を追加して、Coursier 用の JVM オプションを指定します。

オフライン ビルド

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

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

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

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