ルール
エイリアス
ルールソースを表示alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
alias ルールは、ルールを参照できる別の名前を作成します。
エイリアシングは「通常」のターゲットでのみ機能します。特に、package_group と test_suite はエイリアス化できません。
エイリアスは、ターゲットの名前を変更すると多くのファイルに変更が必要になる大規模なリポジトリで役立ちます。複数のターゲットでロジックを再利用する場合は、エイリアス ルールを使用して select 関数呼び出しを保存することもできます。
エイリアス ルールには独自の可視性宣言があります。その他の点では、参照先のルールと同様に動作します（たとえば、エイリアスの testonly は無視され、参照先のルールの testonly が代わりに使用されます）。ただし、いくつかの例外があります。
-
エイリアスがコマンドラインで指定されている場合、テストは実行されません。参照されるテストを実行するエイリアスを定義するには、
tests属性に単一のターゲットを含むtest_suiteルールを使用します。 -
環境グループを定義する場合、
environmentルールのエイリアスはサポートされていません。--target_environmentコマンドライン オプションでもサポートされていません。
例
filegroup(
name = "data",
srcs = ["data.txt"],
)
alias(
name = "other",
actual = ":data",
)
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
actual
|
ラベル（必須） このエイリアスが参照するターゲット。ルールである必要はなく、入力ファイルでもかまいません。 |
config_setting
ルールソースを表示config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
構成可能な属性をトリガーする目的で、想定される構成状態（ビルドフラグまたはプラットフォーム制約として表現）と一致します。このルールの使用方法については、select をご覧ください。一般的な機能の概要については、 構成可能な属性をご覧ください。
例
次のパターンは、--compilation_mode=opt または -c opt を設定するビルド（コマンドラインで明示的に設定するか、.bazelrc ファイルから暗黙的に設定する）に一致します。
config_setting(
name = "simple",
values = {"compilation_mode": "opt"}
)
次の例では、ARM をターゲットとするビルドに一致し、カスタム定義 FOO=bar（bazel build --cpu=arm --define FOO=bar ... など）を適用します。
config_setting(
name = "two_conditions",
values = {
"cpu": "arm",
"define": "FOO=bar"
}
)
次のパターンは、ユーザー定義フラグ
--//custom_flags:foo=1 を設定するビルド（コマンドラインで明示的に設定するか、.bazelrc ファイルから暗黙的に設定する）に一致します。
config_setting(
name = "my_custom_flag_is_set",
flag_values = { "//custom_flags:foo": "1" },
)
次の例は、ラベル //example:glibc_2_25 の constraint_value が存在することを前提として、x86_64 アーキテクチャと glibc バージョン 2.25 のプラットフォームをターゲットとするビルドに一致します。この 2 つ以外に制約値を定義している場合でも、プラットフォームは一致します。
config_setting(
name = "64bit_glibc_2_25",
constraint_values = [
"@platforms//cpu:x86_64",
"//example:glibc_2_25",
]
)
config_setting が最上位のコマンドライン フラグと一致しない場合でも、一部のビルド ターゲットと一致する可能性があります。メモ
- 複数の
config_settingが現在の構成状態と一致した場合の動作については、select をご覧ください。 - 短縮形をサポートするフラグ（
--compilation_modeと-cなど）の場合、values定義では完全な形式を使用する必要があります。これらの呼び出しは、どちらの形式でも自動的に照合されます。 -
フラグが複数の値（
--copt=-Da --copt=-Dbやリスト型の Starlark フラグなど）を受け取る場合、"a"が実際のリストのどこかに存在すれば、values = { "flag": "a" }は一致します。values = { "myflag": "a,b" }も同様に動作します。これは--myflag=a --myflag=b、--myflag=a --myflag=b --myflag=c、--myflag=a,b、--myflag=c,b,aと一致します。正確なセマンティクスはフラグによって異なります。たとえば、--coptは同じインスタンス内の複数の値をサポートしていません。--copt=a,bは["a,b"]を生成し、--copt=a --copt=bは["a", "b"]を生成します（そのため、values = { "copt": "a,b" }は前者と一致しますが、後者とは一致しません）。ただし、--ios_multi_cpus（Apple ルールの場合）は実行します。-ios_multi_cpus=a,bとios_multi_cpus=a --ios_multi_cpus=bの両方で["a", "b"]が生成されます。フラグの定義を確認し、条件を慎重にテストして、正確な期待値を確認します。 - 組み込みのビルドフラグでモデル化されていない条件を定義する必要がある場合は、
Starlark で定義されたフラグを使用します。
--defineを使用することもできますが、サポートが弱く、推奨されません。詳細については、こちらをご覧ください。 - 異なるパッケージで同じ
config_setting定義を繰り返さないようにします。代わりに、正規パッケージで定義された共通のconfig_settingを参照してください。 values、define_values、constraint_valuesは、同じconfig_settingで任意の組み合わせで使用できますが、任意のconfig_settingに対して少なくとも 1 つを設定する必要があります。
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
constraint_values
|
この config_setting に一致するために、ターゲット プラットフォームが指定する必要がある constraint_values の最小セット。（ここでは実行プラットフォームは考慮されません）。プラットフォームが持つ追加の制約値は無視されます。詳細については、
構成可能なビルド属性をご覧ください。2 つの |
define_values
|
ディクショナリ: 文字列 -> 文字列。構成不可。デフォルトは values と同じですが、--define フラグ専用です。
つまり、次のようになります。
config_setting(
name = "a_and_b",
values = {
"define": "a=1",
"define": "b=2",
})
同じキー（
config_setting(
name = "a_and_b",
define_values = {
"a": "1",
"b": "2",
})
|
flag_values
|
ディクショナリ: label -> String; nonconfigurable; デフォルトは values と同じですが、
ユーザー定義のビルドフラグ用です。ユーザー定義のフラグはラベルとして参照され、組み込みフラグは任意の文字列として参照されるため、これは個別の属性です。 |
values
|
ディクショナリ: 文字列 -> 文字列。構成不可。デフォルトは このルールは、 便宜上、構成値はビルドフラグとして指定されます（先頭の コマンドラインでフラグが明示的に設定されていない場合は、デフォルト値が使用されます。辞書にキーが複数回出現する場合、最後のインスタンスのみが使用されます。キーがコマンドラインで複数回設定できるフラグ（
|
filegroup
ルールソースを表示filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
filegroup を使用して、ターゲットのコレクションにわかりやすい名前を付けます。これらの値は、他のルールから参照できます。
ディレクトリを直接参照するのではなく、filegroup を使用することをおすすめします。後者は、ビルドシステムがディレクトリ以下のすべてのファイルを完全に把握していないため、これらのファイルが変更されても再ビルドされない可能性があるため、適切ではありません。glob と組み合わせると、filegroup はすべてのファイルがビルドシステムに明示的に認識されるようにします。
例
2 つのソースファイルで構成される filegroup を作成するには、
filegroup(
name = "mygroup",
srcs = [
"a_file.txt",
"some/subdirectory/another_file.txt",
],
)
または、glob を使用して testdata ディレクトリを検索します。
filegroup(
name = "exported_testdata",
srcs = glob([
"testdata/*.dat",
"testdata/logs/**/*.log",
]),
)
これらの定義を使用するには、任意のルールからラベル付きの filegroup を参照します。
cc_library(
name = "my_library",
srcs = ["foo.cc"],
data = [
"//my_package:exported_testdata",
"//my_package:mygroup",
],
)
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
srcs
|
ラベルのリスト。デフォルトは
|
data
|
ラベルのリスト。デフォルトは
|
output_group
|
文字列。デフォルトは 「出力グループ」は、ターゲットの出力アーティファクトのカテゴリであり、そのルールの実装で指定されます。 |
genquery
ルールソースを表示genquery(name, deps, data, compatible_with, compressed_output, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)
genquery() は、Blaze クエリ言語で指定されたクエリを実行し、結果をファイルにダンプします。
ビルドの一貫性を保つため、クエリは scope 属性で指定されたターゲットの推移閉包のみを対象とします。このルールに違反するクエリは、strict が指定されていないか true の場合、実行時に失敗します（strict が false の場合、範囲外のターゲットは警告とともにスキップされます）。これを回避する最も簡単な方法は、クエリ式と同じラベルをスコープで指定することです。
ここで許可されるクエリとコマンドラインで許可されるクエリの唯一の違いは、ワイルドカード ターゲット仕様（//pkg:* や //pkg:all など）を含むクエリがここでは許可されないことです。これには 2 つの理由があります。1 つ目は、genquery でスコープを指定して、クエリの推移的閉包外のターゲットがその出力に影響を与えないようにする必要があるためです。2 つ目は、BUILD ファイルがワイルドカード依存関係をサポートしていないためです（deps=["//a/..."] などは許可されていません）。
genquery の出力は、確定的な出力を強制するために辞書順に並べ替えられます。ただし、--output=graph|minrank|maxrank の場合、または somepath がトップレベル関数として使用されている場合は除きます。
出力ファイルの名前はルールの名前です。
例
この例では、指定されたターゲットの推移閉包内のラベルのリストをファイルに書き込みます。
genquery(
name = "kiwi-deps",
expression = "deps(//kiwi:kiwi_lib)",
scope = ["//kiwi:kiwi_lib"],
)
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
compressed_output
|
ブール値。デフォルトは True の場合、クエリ出力は GZIP ファイル形式で書き込まれます。この設定は、クエリ出力が大きくなることが予想される場合に、Bazel のメモリ使用量の急増を回避するために使用できます。Bazel は、この設定の値に関係なく、220 バイトを超えるクエリ出力を内部的に圧縮するため、この設定を True に設定しても、保持されるヒープが削減されない可能性があります。ただし、出力ファイルの書き込み時に Bazel が解凍をスキップできるようになります。これはメモリを大量に消費する可能性があります。 |
expression
|
文字列。必須 実行するクエリ。コマンドラインや BUILD ファイルの他の場所とは異なり、ここでのラベルはワークスペースのルート ディレクトリを基準として解決されます。たとえば、ファイルa/BUILD のこの属性のラベル :b は、ターゲット //:b を参照します。 |
opts
|
文字列のリスト。デフォルトは bazel query に渡すことができるコマンドライン オプションに対応しています。--keep_going、--query_file、--universe_scope、--order_results、--order_output などのクエリ オプションは使用できません。ここで指定されていないオプションは、bazel query のコマンドラインと同様にデフォルト値になります。 |
scope
|
ラベルのリスト。必須 クエリのスコープ。クエリは、これらのターゲットの推移閉包外のターゲットにアクセスできません。 |
strict
|
ブール値。デフォルトは |
genrule
ルールソースを表示genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
genrule は、ユーザー定義の Bash コマンドを使用して 1 つ以上のファイルを生成します。
Genrule は、タスクに固有のルールがない場合に使用できる汎用ビルドルールです。たとえば、Bash のワンライナーを実行できます。ただし、C++ ファイルをコンパイルする必要がある場合は、既存の cc_* ルールを使用してください。すべての重い処理はすでに完了しています。
genrule では、コマンド引数を解釈するためにシェルが必要になります。PATH で使用可能な任意のプログラムを参照することも簡単ですが、コマンドが非ハーメチックになり、再現できない可能性があります。単一のツールのみを実行する必要がある場合は、代わりに run_binary の使用を検討してください。
テストの実行に genrule を使用しないでください。テストとテスト結果には、キャッシュ保存ポリシーや環境変数など、特別な免除があります。テストは通常、ビルドの完了後、ターゲット アーキテクチャで実行する必要がありますが、genrule はビルド中、実行アーキテクチャで実行されます（この 2 つは異なる場合があります）。汎用テストルールが必要な場合は、sh_test を使用します。
クロスコンパイルに関する考慮事項
クロス コンパイルについて詳しくは、ユーザー マニュアルをご覧ください。
genrule はビルド中に実行されますが、その出力はビルド後（デプロイやテストなど）に使用されることがよくあります。マイクロコントローラ用の C コードのコンパイルの例を考えてみましょう。コンパイラは C ソースファイルを受け取り、マイクロコントローラで実行されるコードを生成します。生成されたコードは、ビルドに使用された CPU で実行できませんが、C コンパイラ（ソースからコンパイルされた場合）自体は実行する必要があります。
ビルドシステムは、実行構成を使用してビルドが実行されるマシンを記述し、ターゲット構成を使用してビルドの出力が実行されるマシンを記述します。これらの各項目を構成するオプションが用意されており、競合を避けるために対応するファイルが個別のディレクトリに分離されます。
genrules の場合、ビルドシステムは依存関係が適切にビルドされるようにします。ターゲット構成に対して srcs が（必要に応じて）ビルドされ、実行構成に対して tools がビルドされ、出力はターゲット構成のものとみなされます。また、genrule コマンドが対応するツールに渡すことができる
「Make」変数も提供します。
genrule が deps 属性を定義しないのは意図的なものです。他の組み込みルールは、ルール間で渡される言語依存のメタ情報を使用して、依存ルールを処理する方法を自動的に決定しますが、genrule ではこのレベルの自動化はできません。Genrule は、ファイルと runfile のレベルでのみ機能します。
特別なケース
Exec-exec コンパイル: ビルド システムで、ビルド中に出力も実行できるように genrule を実行する必要がある場合があります。たとえば、genrule がカスタム コンパイラをビルドし、そのコンパイラが別の genrule で使用される場合、最初の genrule は exec 構成の出力を生成する必要があります。これは、コンパイラが別の genrule で実行される場所であるためです。この場合、ビルドシステムは自動的に適切な処理を行います。ターゲット構成ではなく、実行構成の最初の genrule の srcs と outs をビルドします。詳しくは、ユーザー マニュアルをご覧ください。
JDK と C++ ツール: JDK または C++ コンパイラ スイートのツールを使用するには、ビルドシステムが使用する変数のセットを提供します。詳しくは、「Make」変数をご覧ください。
Genrule 環境
genrule コマンドは、コマンドまたはパイプラインが失敗した場合に set -e -o pipefail を使用して失敗するように構成された Bash シェルによって実行されます。
ビルドツールは、PATH、PWD、TMPDIR などのコア変数のみを定義するサニタイズされたプロセス環境で Bash コマンドを実行します。ビルドの再現性を確保するため、ユーザーのシェル環境で定義されたほとんどの変数は genrule のコマンドに渡されません。ただし、Bazel（Blaze ではない）はユーザーの PATH 環境変数の値を渡します。PATH の値が変更されると、Bazel は次のビルドでコマンドを再実行します。
genrule コマンドは、コマンド自体の子であるプロセスを接続する場合を除き、ネットワークにアクセスしてはなりません。ただし、このルールは現在強制されていません。
ビルドシステムは、既存の出力ファイルを自動的に削除しますが、genrule を実行する前に必要な親ディレクトリを作成します。また、失敗した場合は出力ファイルも削除します。
一般的なアドバイス
- genrule によって実行されるツールが決定論的で密閉型であることを確認してください。タイムスタンプを出力に書き込まず、セットとマップには安定した順序を使用し、出力には相対ファイルパスのみを書き込み、絶対パスは書き込まないようにする必要があります。このルールに従わないと、予期しないビルド動作（Bazel が再ビルドしない genrule がある）が発生し、キャッシュのパフォーマンスが低下します。
- 出力、ツール、ソースに
$(location)を多用します。構成ごとに異なる出力ファイルが分離されているため、genrule はハードコードされたパスや絶対パスに依存できません。 - 同じまたは非常に類似した genrule が複数の場所で使用される場合は、共通の Starlark マクロを作成してください。genrule が複雑な場合は、スクリプトまたは Starlark ルールとして実装することを検討してください。これにより、読みやすさとテストのしやすさが向上します。
- 終了コードが genrule の成功または失敗を正しく示していることを確認してください。
- 情報メッセージを stdout または stderr に書き込まないでください。デバッグには役立ちますが、ノイズになりやすいので、genrule が成功した場合は何も出力しないようにします。一方、失敗した genrule は適切なエラー メッセージを生成する必要があります。
$$evaluates to a$, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such asls $(dirname $x), one must escape it thus:ls $$(dirname $$x)。- シンボリック リンクとディレクトリの作成は避けてください。Bazel は genrule によって作成されたディレクトリ/シンボリック リンク構造をコピーせず、ディレクトリの依存関係チェックが不適切です。
- 他のルールで genrule を参照する場合は、genrule のラベルまたは個々の出力ファイルのラベルを使用できます。一方のアプローチが読みやすい場合もあれば、他方のアプローチが読みやすい場合もあります。使用側のルールの
srcsで名前で出力を参照すると、genrule の他の出力を誤って取得することを回避できますが、genrule が多くの出力を生成する場合は面倒になる可能性があります。
例
この例では、foo.h が生成されます。コマンドは入力を受け取らないため、ソースはありません。コマンドによって実行される「バイナリ」は、genrule と同じパッケージ内の perl スクリプトです。
genrule(
name = "foo",
srcs = [],
outs = ["foo.h"],
cmd = "./$(location create_foo.pl) > \"$@\"",
tools = ["create_foo.pl"],
)
次の例は、filegroup
と別の genrule の出力を使用する方法を示しています。明示的な $(location) ディレクティブの代わりに $(SRCS) を使用しても機能します。この例では、説明のために後者を使用しています。
genrule(
name = "concat_all_files",
srcs = [
"//some:files", # a filegroup with multiple files in it ==> $(locations)
"//other:gen", # a genrule with a single output ==> $(location)
],
outs = ["concatenated.txt"],
cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 他の BUILD ルールの srcs セクションまたは deps セクションで、このルールを名前で参照できます。ルールがソースファイルを生成する場合は、srcs 属性を使用する必要があります。 |
srcs
|
ラベルのリスト。デフォルトは
この属性は
ビルドシステムは、genrule コマンドを実行する前にこれらの前提条件がビルドされるようにします。これらは、元のビルド リクエストと同じ構成を使用してビルドされます。これらの前提条件のファイル名は、 |
outs
|
このルールによって生成されたファイルのリスト。 出力ファイルはパッケージ境界を越えてはなりません。出力ファイル名は、パッケージからの相対名として解釈されます。
genrule コマンドは、各出力ファイルを所定の場所に作成することが想定されています。ロケーションは、 |
cmd
|
文字列。デフォルトは $(location)
と 「Make」変数の置換の対象となります。
cmd_bash、cmd_ps、cmd_bat のいずれにも該当しない場合のフォールバックです。
コマンドラインの長さがプラットフォームの上限（Linux/macOS では 64K、Windows では 8K）を超えると、genrule はコマンドをスクリプトに書き込み、そのスクリプトを実行して回避します。これは、すべての cmd 属性（ |
cmd_bash
|
文字列。デフォルトは この属性は |
cmd_bat
|
文字列。デフォルトは この属性は、
|
cmd_ps
|
文字列。デフォルトは この属性は、
Powershell を使いやすく、エラーが発生しにくくするために、genrule で Powershell コマンドを実行する前に、次のコマンドを実行して環境を設定します。
|
executable
|
ブール値。構成不可。デフォルトは
このフラグを True に設定すると、出力は実行可能ファイルになり、 生成された実行可能ファイルのデータ依存関係の宣言はサポートされていません。 |
local
|
ブール値。デフォルトは
True に設定すると、このオプションは
これは、タグ（ |
message
|
文字列。デフォルトは
このビルドステップの実行時に出力される進行状況メッセージ。デフォルトでは、メッセージは「出力を生成しています」（または同様の無味乾燥なメッセージ）ですが、より具体的なメッセージを指定することもできます。この属性は、 |
output_licenses
|
ライセンス タイプ。デフォルトは common attributes
を参照してください。
|
output_to_bindir
|
ブール値。構成不可。デフォルトは
True に設定すると、このオプションにより、出力ファイルが |
tools
|
ラベルのリスト。デフォルトは
ビルドシステムは、genrule コマンドを実行する前にこれらの前提条件がビルドされるようにします。これらのツールはビルドの一部として実行されるため、exec 構成を使用してビルドされます。個々の
|
starlark_doc_extract
ルールソースを表示starlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)
starlark_doc_extract() は、特定の .bzl ファイルまたは .scl ファイルで定義または再エクスポートされたルール、関数（マクロを含む）、アスペクト、プロバイダのドキュメントを抽出します。このルールの出力は、Bazel ソースツリーの stardoc_output.proto で定義されている ModuleInfo バイナリ proto です。
暗黙的な出力ターゲット
name.binaryproto（デフォルトの出力）:ModuleInfoバイナリ プロト。name.textproto（明示的にリクエストされた場合にのみビルド）:name.binaryprotoのテキスト プロトコル バージョン。
警告: このルールの出力形式は安定しているとは限りません。これは主に Stardoc の内部使用を目的としています。
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
deps
|
ラベルのリスト。デフォルトは src によって load() される Starlark ファイルをラップするターゲットのリスト。これらのターゲットは、通常の使用では bzl_library ターゲットである必要がありますが、starlark_doc_extract ルールではこれが強制されず、DefaultInfo で Starlark ファイルを提供する任意のターゲットが受け入れられます。ラップされた Starlark ファイルはソースツリー内のファイルである必要があります。Bazel は生成されたファイルを |
src
|
ラベル（必須） ドキュメントを抽出する Starlark ファイル。これはソースツリー内のファイルである必要があります。Bazel は生成されたファイルを |
render_main_repo_name
|
ブール値。デフォルトは //foo:bar.bzl は @main_repo_name//foo:bar.bzl として出力されます）。メイン リポジトリに使用する名前は、メイン リポジトリの この属性は、同じリポジトリ内でのみ使用される Starlark ファイルのドキュメントを生成する場合は |
symbol_names
|
文字列のリスト。デフォルトは
|
test_suite
ルールソースを表示test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
test_suite は、人間にとって「有用」と見なされる一連のテストを定義します。これにより、プロジェクトで「チェックイン前に実行する必要があるテスト」、「プロジェクトのストレステスト」、「すべての小規模テスト」などのテストセットを定義できます。blaze test コマンドはこの種の編成を尊重します。blaze test //some/test:suite のような呼び出しの場合、Blaze はまず //some/test:suite ターゲットによって推移的に含まれるすべてのテスト ターゲットを列挙し（これを「test_suite 拡張」と呼びます）、次に Blaze はこれらのターゲットをビルドしてテストします。
例
現在のパッケージ内のすべての小規模テストを実行するテストスイート。
test_suite(
name = "small_tests",
tags = ["small"],
)
指定されたテストセットを実行するテストスイート:
test_suite(
name = "smoke_tests",
tests = [
"system_unittest",
"public_api_unittest",
],
)
不安定でない現在のパッケージ内のすべてのテストを実行するテストスイート。
test_suite(
name = "non_flaky_test",
tags = ["-flaky"],
)
引数
| 属性 | |
|---|---|
name |
名前（必須） このターゲットの一意の名前。 |
tags
|
文字列のリスト。設定不可。デフォルトは 「-」で始まるタグは除外タグと見なされます。先行する「-」文字はタグの一部とは見なされないため、「-small」のスイートタグはテストの「small」サイズと一致します。それ以外のタグはすべてポジティブ タグとみなされます。 必要に応じて、正のタグをより明確にするために、タグの先頭に「+」文字を使用することもできます。この文字はタグのテキストの一部として評価されません。正と負の区別を読みやすくするだけです。 陽性タグのすべてに一致し、陰性タグのいずれにも一致しないテストルールのみがテストスイートに含まれます。これは、除外されたテストの依存関係のエラーチェックがスキップされるという意味ではありません。スキップされたテストの依存関係は、引き続き有効である必要があります（可視性制約によってブロックされていないなど）。
テストの
相互に排他的なタグ（すべての小規模テストと中規模テストなど）を含む |
tests
|
任意の言語のテストスイートとテスト ターゲットのリスト。
ここでは、言語に関係なく任意の
|