リポジトリのルール

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

このページでは、リポジトリルールの作成方法と例について説明します。詳しく見ていきます

外部リポジトリは、WORKSPACE ファイルでのみ使用できるルールで、Bazel の読み込みフェーズで非密閉型のオペレーションを可能にします。各外部リポジトリルールは、独自の BUILD ファイルとアーティファクトを含む独自のワークスペースを作成します。サードパーティ製品への依存に使用する（Maven パッケージライブラリなど）だけでなく、BUILD ファイルの生成も行えます Bazel が実行されているホストに固有のものです。

リポジトリルールの作成

.bzl ファイルでは、次のコマンドを使用します。新しいリポジトリを作成するための repository_rule 関数グローバル変数に格納します。

カスタムリポジトリルールは、ネイティブリポジトリルールと同じように使用できます。これは、必須の name 属性と、そのビルドファイルに存在するすべてのターゲットがある @<name>//package:target として参照できます。ここで、<name> は name 属性。

ルールは、明示的にビルドする場合、またはビルドの依存関係である場合に読み込まれます。この場合、Bazel は implementation 関数を実行します。この関数で、リポジトリ、そのコンテンツ、BUILD ファイルの作成方法を記述します。

属性

属性は、attrs ルール引数に辞書として渡されるルール引数です。定義されている属性とその型は、リポジトリルールを使用します。url 属性と sha256 属性を文字列として定義する例:

local_repository = repository_rule(
    implementation=_impl,
    local=True,
    attrs={
        "url": attr.string(mandatory=True)
        "sha256": attr.string(mandatory=True)
    }
)

実装関数内の属性にアクセスするには、repository_ctx.attr.<attribute_name> を使用します。

def _impl(repository_ctx):
    url = repository_ctx.attr.url
    checksum = repository_ctx.attr.sha256

すべての repository_rule には、暗黙的に定義された属性があります（ビルドと同様）ルール）が含まれます。暗黙的な属性は name（ビルドルールと同様）と repo_mapping。リポジトリルールの名前には repository_ctx.name でアクセスできます。repo_mapping の意味は、ネイティブリポジトリルールの local_repository と new_local_repository と同じです。

属性名が _ で始まる場合、その属性は非公開であり、ユーザーが設定することはできません。

実装関数

すべてのリポジトリルールに implementation 関数が必要です。ルールの実際のロジックが含まれており、読み込みフェーズで厳密に実行されます。

この関数には、入力パラメータが 1 つ（repository_ctx）あります。この関数は、指定されたパラメータでルールが再現可能であることを示す None を返すか、そのルールを同じリポジトリを生成する再現可能なルールに変換する一連のパラメータを含む辞書を返します。対象たとえば、Git リポジトリを追跡するルールの場合、特定の commit 識別子を、元々作成済みのフローティングブランチではなく、あります。

入力パラメータ repository_ctx を使用すると、属性値へのアクセス、非密閉関数（バイナリの検出、バイナリの実行、リポジトリでのファイルの作成、ファイルのダウンロードインターネットからの情報）詳細については、ライブラリをご覧ください。例:

def _impl(repository_ctx):
  repository_ctx.symlink(repository_ctx.attr.path, "")

local_repository = repository_rule(
    implementation=_impl,
    ...)

実装関数はいつ実行されますか？

リポジトリの実装関数は、Bazel がそのリポジトリのターゲットを必要とするときに実行されます。たとえば、別のターゲット（別のリポジトリ内）がそのターゲットに依存している場合や、コマンドラインでそのターゲットが指定されている場合などです。実装関数は、ファイルシステムにリポジトリを作成することが期待されます。これを「取得」と呼びます。使用できます。

通常のターゲットとは異なり、リポジトリが変更されてリポジトリが異なる状態になる場合でも、リポジトリが再取得されるわけではありません。これは、 Bazel で変更を検出できない場合や、変更を実行してしまう場合があります。すべてのビルドで過剰なオーバーヘッドが発生する受信できます。したがって、リポジトリが再取得されるのは、次の点が変わります。

リポジトリの宣言に渡されるパラメータは、 WORKSPACE ファイル。
リポジトリの実装を構成する Starlark コード。
repository_ctx の関数に渡される環境変数の値 getenv() メソッドか、environ repository_rule。これらの環境変数の値は、--repo_env フラグを使用してコマンドラインでハードコードできます。
read() や execute() などに渡されるファイルの内容ラベルによって参照される repository_ctx のメソッド（例: //mypkg:label.txt だが mypkg/label.txt ではない）
bazel sync が実行されたとき。

repository_rule には、リポジトリの再取得タイミングを制御する 2 つのパラメータがあります。

configure フラグが設定されている場合、--configure パラメータが渡された場合にのみ、bazel sync でリポジトリが再取得されます（属性が設定されていない場合、このコマンドで再取得は行われません）。
local フラグが設定されている場合、上記のケースに加えて、Bazel サーバーが再起動されたとき、またはリポジトリの宣言に影響するファイル（WORKSPACE ファイルや読み込むファイルなど）が変更されたときに、リポジトリが再取得されます。この変更がリポジトリの宣言やコードの変更につながったかどうかは関係ありません。

この場合、ローカル以外のリポジトリは再取得されません。これは、これらのリポジトリがネットワークと通信するか、それ以外の場合は費用がかかると考えられているためです。

実装関数の再起動

実装関数は、リポジトリの取得中に、リクエストした依存関係が欠落している場合に再起動できます。その場合、実装関数が停止し、欠落している依存関係が解決され、依存関係が解決されると、関数が再実行されます。宛先コストのかかる不要な再起動（ネットワークアクセスが悪化することもあるため、繰り返す必要がある場合）、ラベル引数はすべてプリフェッチされます。ラベル引数は既存のファイルに解決できます。関数の実行中にのみ作成された文字列またはラベルからパスを解決しても、再起動が発生することがあります。

外部リポジトリの強制再取得

外部リポジトリの定義や依存関係が変更されていないにもかかわらず、古くなることがあります。たとえば、ソースをフェッチするリポジトリは、特定のブランチをフォローすると、新しい commit がそのブランチで利用できますこの場合、bazel sync を呼び出して、すべての外部リポジトリを無条件に再取得するよう bazel に指示できます。

また、一部のルールはローカルマシンを検査するため、ローカルマシンがアップグレードされると古くなる可能性があります。ここで Bazel に外部リポジトリを再取得するのは repository_rule 定義に configure 属性が設定されている場合は、bazel sync --configure を使用します。

例

C++ 自動構成ツールチェーン: リポジトリルールを使用して、ローカルの C++ コンパイラ、環境、C++ コンパイラがサポートするフラグを検索し、Bazel の C++ 構成ファイルを自動的に作成します。
Go リポジトリは、複数の repository_rule を使用して、Go ルールの使用に必要な依存関係のリストを定義します。
rules_jvm_external は、デフォルトで @maven という外部リポジトリを作成します。このリポジトリは、伝播依存関係ツリー内のすべての Maven アーティファクトのビルドターゲットを生成します。