リポジトリのルール

<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 ファイルの作成方法を記述します。

属性

属性はルール引数です（url や sha256 など）。リストには、 リポジトリ ルールを定義するときに、属性とその型を指定できます。

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

属性にアクセスするには、repository_ctx.attr.<attribute_name> を使用します。

すべての 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,
    ...)

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

リポジトリが local として宣言されている場合は、依存関係を変更します。 依存関係グラフ内に存在する（WORKSPACE ファイル自体を含む）は、 実装関数が実行されます。

実装関数が依存関係にある場合は、その関数を再起動できます。 不足していることがわかります。実装関数の最初の部分は、 依存関係の解決後に再度実行されます。避けるべきこと 不必要な再起動（ネットワーク アクセスの影響を受けるため、 繰り返す必要がある場合）、ラベル引数はすべてプリフェッチされます。 ラベル引数は既存のファイルに解決できます。なお、 実行時にのみ作成された文字列またはラベルからのパス 再起動が必要になる可能性があります。

最後に、local 以外のリポジトリの場合は、次の変更のみを行います。 再起動の原因となる場合があります。

  • リポジトリ ルールの定義に必要な .bzl ファイル。
  • WORKSPACE ファイル内のリポジトリ ルールの宣言。
  • environ で宣言された環境変数の値 属性の repository_rule 使用します。これらの環境変数の値は、Google Cloud コマンドラインで --action_env フラグを指定します（ただし、このフラグはビルドのすべてのアクションを無効にします）。
  • ラベルによって使用および参照されるファイルのコンテンツ（ mypkg/label.txt ではなく //mypkg:label.txt）。

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

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

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

例

  • C++ 自動構成ツールチェーン: リポジトリ ルールを使用して、 Bazel の C++ 構成ファイル。ローカル C++ コンパイラである 環境と C++ コンパイラがサポートするフラグが含まれます。

  • Go リポジトリ 複数の repository_rule を使用して、依存関係のリストを定義します。 必要があります。

  • rules_jvm_external は、 ビルド ターゲットを生成する、デフォルトで @maven という外部リポジトリ （推移的依存関係ツリー内のすべての Maven アーティファクトに対して）