このページでは、リポジトリ ルールの作成方法と例について説明します。 詳しく見ていきます
外部リポジトリは、WORKSPACE ファイルでのみ使用できるルールで、Bazel の読み込みフェーズで非密閉型のオペレーションを可能にします。各外部リポジトリ ルールにより、独自のワークスペースが作成され、
独自の BUILD ファイルとアーティファクト。サードパーティ ライブラリ（Maven パッケージ化ライブラリなど）に依存するために使用できますが、Bazel が実行されているホストに固有の BUILD ファイルを生成するためにも使用できます。
リポジトリ ルールの作成
.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 関数が必要です。ルールの実際のロジックが含まれており、読み込みフェーズで厳密に実行されます。
この関数には、入力パラメータが 1 つ（repository_ctx）あります。この関数は、指定されたパラメータでルールが再現可能であることを示す None を返すか、そのルールを同じリポジトリを生成する再現可能なルールに変換する一連のパラメータを含む辞書を返します。たとえば、Git リポジトリを追跡するルールの場合、元に指定されたフローティング ブランチではなく、特定の commit ID を返すことになります。
入力パラメータ repository_ctx は、属性値と非完全関数（バイナリの検索、バイナリの実行、リポジトリ内のファイルの作成、インターネットからのファイルのダウンロード）にアクセスするために使用できます。詳細については、ライブラリをご覧ください。例:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
実装関数はいつ実行されますか？
リポジトリの実装関数は、Bazel がそのリポジトリのターゲットを必要とするときに実行されます。たとえば、別のターゲット（別のリポジトリ内）がそのターゲットに依存している場合や、コマンドラインでそのターゲットが指定されている場合などです。「 そして、ファイル内にリポジトリを作成することが期待されます。 ありませんこれを「取得」と呼びます。使用できます。
通常のターゲットとは異なり、リポジトリが変更されてリポジトリが異なる状態になる場合でも、リポジトリが再取得されるわけではありません。これは、Bazel が変更を検出できないものや、ビルドごとに過剰なオーバーヘッドが発生するもの（ネットワークから取得されるものなど）があるためです。したがって、リポジトリは次のいずれかが変更された場合にのみ再取得されます。
WORKSPACEファイルのリポジトリの宣言に渡されるパラメータ。- リポジトリの実装を構成する Starlark コード。
repository_ruleのenviron属性で宣言された環境変数の値。これらの環境変数の値はコマンドに直接接続できます。 行を--action_envフラグを使用します（このフラグはビルドのすべてのアクションを無効にします）。- ラベルによって参照される
repository_ctxのread()、execute()などのメソッドに渡されるファイルの内容（//mypkg:label.txtなど、mypkg/label.txtは除く） bazel syncが実行されたとき。
repository_rule には、リポジトリの再取得タイミングを制御する 2 つのパラメータがあります。
configureフラグが設定されている場合、リポジトリは--configureパラメータが渡された場合はbazel sync（ 属性が設定されていない場合、このコマンドで再取得は行われません）localフラグが設定されている場合は、上記のケースに加えて、リポジトリが設定されます。 Bazel サーバーの再起動時や、影響を受けるファイルがある場合にも、 リポジトリの変更の宣言（例:WORKSPACEファイルやファイル その変更が原因となった変更があったかどうかに関係なく、 リポジトリまたはそのコードの宣言。この場合、ローカル以外のリポジトリは再取得されません。これは、これらのリポジトリがネットワークと通信するか、それ以外の場合は費用がかかると考えられているためです。
実装関数の再起動
実装関数は、リポジトリの取得中に、リクエストした依存関係が欠落している場合に再起動できます。その場合、 実装関数が停止し、欠落している依存関係が解決され、 依存関係が解決されると、関数が再実行されます。不要な再起動（ネットワーク アクセスを繰り返す必要があるためコストが高い）を回避するため、すべてのラベル引数を既存のファイルに解決できる場合は、ラベル引数がプリフェッチされます。関数の実行中にのみ作成された文字列またはラベルからパスを解決しても、再起動が発生することがあります。
外部リポジトリの強制再取得
外部リポジトリは、変更されずに古くなってしまうことがあります。
必要があります。たとえば、ソースをフェッチするリポジトリがサードパーティ リポジトリの特定のブランチに従っていて、そのブランチで新しい commit が利用可能である場合。この場合、bazel sync を呼び出して、すべての外部リポジトリを無条件に再取得するよう bazel に指示できます。
また、一部のルールはローカルマシンを検査するため、ローカルマシンがアップグレードされると古くなる可能性があります。ここで Bazel に
外部リポジトリを再取得するのは
repository_rule
定義に configure 属性が設定されている場合は、bazel sync --configure を使用します。
例
C++ 自動構成ツールチェーン: リポジトリルールを使用して、ローカルの C++ コンパイラ、環境、C++ コンパイラがサポートするフラグを検索し、Bazel の C++ 構成ファイルを自動的に作成します。
Go リポジトリは、複数の
repository_ruleを使用して、Go ルールの使用に必要な依存関係のリストを定義します。rules_jvm_external は、デフォルトで
@mavenという外部リポジトリを作成します。このリポジトリは、伝播依存関係ツリー内のすべての Maven アーティファクトのビルド ターゲットを生成します。