このページでは、リポジトリ ルールの作成方法と例について説明します。 詳しく見ていきます
外部リポジトリは、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 アーティファクトに対して）