このページでは、リポジトリ ルールの作成方法と例について説明します。 詳しく見ていきます
外部リポジトリは、Google Cloud プロジェクトまたは
WORKSPACE
ファイルで指定。読み込みフェーズで非密閉オペレーションを有効にします。
使用されます。各外部リポジトリ ルールにより、独自のワークスペースが作成され、
独自の BUILD
ファイルとアーティファクト。サードパーティ製品への依存に使用する
(Maven パッケージ ライブラリなど)だけでなく、BUILD
ファイルの生成も行えます
Bazel が実行されているホストに固有のものです。
リポジトリ ルールの作成
.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
関数が必要です。これには、
読み込みフェーズでのみ実行されます。
この関数には、入力パラメータ 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,
...)
実装関数はいつ実行されますか。
リポジトリの実装機能は、Bazel で以下が必要な場合に実行されます。 できます。たとえば、別のターゲット(別の VM など)に 依存するか、コマンドラインで言及されているかを確認します。「 そして、ファイル内にリポジトリを作成することが期待されます。 ありませんこれを「取得」と呼びます。使用できます。
通常のターゲットとは対照的に、リポジトリは必ずしも リポジトリが変わってしまうような変更が起こります。これは、 Bazel で変更を検出できない場合や、変更を実行してしまうことが すべてのビルドで過剰なオーバーヘッドが発生する 受信できます。したがって、リポジトリが再取得されるのは、 次の点が変わります。
- リポジトリの宣言に渡されるパラメータは、
WORKSPACE
ファイル。 - リポジトリの実装を構成する Starlark コード。
repository_ctx
の関数に渡される環境変数の値getenv()
メソッドを使用するか、environ
repository_rule
。値 これらの環境変数のいくつかは、コマンドラインで--repo_env
フラグ。read()
やexecute()
などに渡されるファイルの内容 ラベルによって参照されるrepository_ctx
のメソッド(例://mypkg:label.txt
だがmypkg/label.txt
ではない)bazel sync
が実行されたとき。
リポジトリのタイミングを制御する repository_rule
の 2 つのパラメータがあります。
次のように再取得します。
configure
フラグが設定されている場合、リポジトリは--configure
パラメータが渡された場合はbazel sync
( 属性が設定されていない場合、このコマンドで再取得は行われません)local
フラグが設定されている場合は、上記のケースに加えて、リポジトリが設定されます。 Bazel サーバーの再起動時や、影響を受けるファイルがある場合にも、 リポジトリの変更の宣言(例:WORKSPACE
ファイルやファイル その変更が原因となった変更があったかどうかに関係なく、 リポジトリまたはそのコードの宣言。この場合、ローカル以外のリポジトリは再取得されません。その理由は、 これらのリポジトリは、ネットワークと通信するか、 高価です
実装関数の再起動
リポジトリのオペレーション中に実装関数を再起動できます。 リクエストされた依存関係が欠落している場合にフェッチされます。その場合、 実装関数が停止し、欠落している依存関係が解決され、 依存関係が解決されると、関数が再実行されます。宛先 コストのかかる不要な再起動(ネットワーク アクセスが悪化することもあるため、 繰り返す必要がある場合)、ラベル引数はすべてプリフェッチされます。 ラベル引数は既存のファイルに解決できます。なお、 実行時にのみ作成された文字列またはラベルからのパス 再起動が必要になる可能性があります。
外部リポジトリの強制再取得
外部リポジトリは、変更されずに古くなってしまうことがあります。
必要があります。たとえば、ソースをフェッチするリポジトリは、
特定のブランチをフォローすると、新しい commit が
そのブランチで利用できますこの場合、Bazel にすべてのリソースを再取得するよう
bazel sync
を呼び出して外部リポジトリを無条件に許可できます。
さらに、ローカルマシンを検査するルールがあり、
古いバージョンだと判断できますここで Bazel に
外部リポジトリを再取得するのは
repository_rule
定義に configure
属性が設定されている場合は、bazel sync --configure
を使用します。
例
C++ 自動構成ツールチェーン: リポジトリ ルールを使用して、 Bazel の C++ 構成ファイル。ローカル C++ コンパイラである 環境と C++ コンパイラがサポートするフラグが含まれます。
Go リポジトリ 複数の
repository_rule
を使用して、依存関係のリストを定義します。 必要があります。rules_jvm_external は、 ビルド ターゲットを生成する、デフォルトで
@maven
という外部リポジトリ (推移的依存関係ツリー内のすべての Maven アーティファクトに対して)