リポジトリのルール

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

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

外部リポジトリはディレクトリツリーで、 Bazel ビルドで使用可能なソースファイルが含まれています。このファイルは対応するリポジトリルールを実行します。Repo はさまざまな環境で定義できます。最終的には、先ほどと同じように、Repo ルールを呼び出して、各リポジトリを定義します。ビルドターゲットは、ビルドルールを呼び出すことで定義されます。これらを使用して Maven パッケージライブラリなど）を使用でき、 Bazel が実行されているホストに固有の BUILD ファイル。

リポジトリルールの定義

.bzl ファイルでは、次のコマンドを使用します。 repository_rule 関数でグローバル変数に格納します。Repo ルールを定義したら、リポジトリを定義する関数として呼び出すことができます。この呼び出しは通常モジュール拡張実装の内部から実行する使用します。

リポジトリルールの定義を構成する主な 2 つのコンポーネントは、その属性スキーマと実装します。属性スキーマは、リソースの名前とタイプを渡され、実装関数は、リポジトリルールの呼び出しに自動的に実行します。

属性

属性は、リポジトリルールの呼び出しに渡される引数です。Google Cloud のリポジトリルールで受け入れられる属性を指定するには、次の場合に attrs 引数を使用します。リポジトリルールは repository_rule の呼び出しで定義されます。この例で、文字列としての url 属性と sha256 属性:

http_archive = repository_rule(
    implementation=_impl,
    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 があります。これは string 属性が魔法のように機能します。入力として指定した場合、見かけ上のリポジトリ名を使用します。読み取られると repository_ctx.attr.name を使用してリポジトリルールの実装関数を実行すると、指定します。

実装関数

すべてのリポジトリルールに implementation 関数が必要です。これには、読み込みフェーズでのみ実行されます。

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

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

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

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

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

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

通常のターゲットとは対照的に、リポジトリは必ずしもリポジトリが変わる原因となるような変更が加えられた場合です。これは、 Bazel で変更を検出できない場合や、変更を実行してしまうことがすべてのビルドで過剰なオーバーヘッドが発生する受信できます。したがって、リポジトリが再取得されるのは、次の点が変わります。

Repo ルールの呼び出しに渡される属性。
Repo ルールの実装を構成する Starlark コード。
repository_ctx の関数に渡される環境変数の値 getenv() メソッドを使用するか、environ repository_rule。値これらの環境変数のいくつかは、コマンドラインで --repo_env フラグ。
read() や execute() などに渡されるファイルの内容ラベルによって参照される repository_ctx のメソッド（例: //mypkg:label.txt だが mypkg/label.txt ではない）
bazel fetch --force が実行されたとき。

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

configure フラグが設定されている場合、リポジトリは --configure パラメータが渡された場合は bazel fetch（属性が設定されていない場合、このコマンドで再取得は行われません）
local フラグが設定されている場合、上記のケースに加えて、リポジトリは Bazel サーバーの再起動時にも再取得されます。

実装関数の再起動

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

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

外部リポジトリは、変更を加えずに古いものになる場合があります。必要があります。たとえば、ソースを取得するリポジトリは、特定のブランチをフォローすると、新しい commit がそのブランチで利用できますこの場合、Bazel にすべてのリソースを再取得するよう bazel fetch --force --all を呼び出して外部リポジトリに無条件で付与します。

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

例

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