リポジトリのルール

<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 アーティファクトに対して)