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

<ph type="x-smartling-placeholder"></ph> 問題を報告するソースを表示夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

可能な限り、プロジェクトにはバージョンポリシーを 1 つだけ設定してください。必要であり、最終的にバイナリです。それ以外の場合は、依存関係をシャドーイングできます。

自分のプロジェクト/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

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 インスタンスがネットワークで外部アドレスを解決またはアクセスできないため、Network unreachable 例外やビルドエラーが発生する可能性があります。そのような場合は 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 環境へ変数を使用して、VM の JVM オプションを指定 Coursier。

オフラインビルド

モバイルデバイスを使用して移動する場合など、ビルドをオフラインで実行したい場合もあります。あります。このようなシンプルなユースケースでは、必要なリポジトリを bazel fetch または bazel sync。追加のリポジトリの取得を無効にするには、 --nofetch オプションを使用します。

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

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

Bazel では、リポジトリルール内の任意のコマンドを、知らないうちに実行できるネットワークに対して呼び出しを行うと、完全にオフラインのビルドを適用できません。宛先ビルドがオフラインで正しく機能するかどうかをテストし、ネットワーク Bazel はブートストラップで実行します。テスト）。