リポジトリのルール

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

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

外部リポジトリは、Google Cloud プロジェクトまたは WORKSPACE ファイルで指定。読み込みフェーズで非密閉オペレーションを有効にします。使用されます。各外部リポジトリルールにより、独自のワークスペースが作成され、独自の 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 関数が必要です。これには、読み込みフェーズでのみ実行されます。

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

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

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

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

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

リポジトリの実装機能は、Bazel で以下が必要な場合に実行されます。できます。たとえば、別のターゲット（別の VM など）に依存するか、コマンドラインで言及されているかを確認します。「そして、ファイル内にリポジトリを作成することが期待されます。ありませんこれを「取得」と呼びます。使用できます。

通常のターゲットとは対照的に、リポジトリは必ずしもリポジトリが変わってしまうような変更が起こります。これは、 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 にすべてのリソースを再取得するよう bazel sync を呼び出して外部リポジトリを無条件に許可できます。

さらに、ローカルマシンを検査するルールがあり、古いバージョンだと判断できますここで Bazel に外部リポジトリを再取得するのは repository_rule 定義に configure 属性が設定されている場合は、bazel sync --configure を使用します。

例

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