ルール
エイリアス
ルールのソースを表示alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
alias ルールは、ルールの別名を作成します。
エイリアス化は「regular」できます。具体的には、package_group
test_suite にはエイリアスを設定できません。
エイリアスの設定は、大規模なリポジトリで、ターゲットの名前の変更に 変更されます。また、エイリアス ルールを使用して、 select 関数呼び出しを行うと、そのロジックを 複数のターゲットにできます。
エイリアス ルールには独自の公開設定宣言があります。その他すべての点では、 （たとえば、エイリアスの testonly は無視されます。また、testonly-ness が代わりに使用されます）。ただし、次のような例外があります。
-
コマンドラインにエイリアスが指定されている場合、テストは実行されません。エイリアスを定義するには
機能する場合は、
test_suiteを使用してください。testsに単一のターゲットがあるルール 属性です。 -
環境グループを定義する場合、
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: このルールの使用方法と、<ph type="x-smartling-placeholder"></ph> 構成可能な属性: 一般的な機能の概要をご覧ください。
例
以下は、--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" },
)
以下は、x86_64 アーキテクチャのプラットフォームと glibc をターゲットとするビルドと一致します。
バージョン 2.25（ラベル付きの constraint_value の存在を前提）
//example:glibc_2_25。なお、プラットフォームは、
使用できます。
config_setting(
name = "64bit_glibc_2_25",
constraint_values = [
"@platforms//cpu:x86_64",
"//example:glibc_2_25",
]
)
いずれの場合も、ビルド内で構成を変更できます。たとえば、
ターゲットをその依存関係とは異なるプラットフォームにビルドする必要がある。つまり、たとえ
config_setting はトップレベルのコマンドライン フラグと一致しません。一致する可能性はあります。
いくつかのビルド ターゲットを作成します。
メモ
- 複数のケースが同時に実行された場合の動作については、select をご覧ください。
config_settingが現在の構成状態と一致する。 - 省略形をサポートするフラグの場合（例:
--compilation_mode、-c）、valuesの定義では完全な形式を使用する必要があります。これらは自動的に 呼び出しを照合できます。 -
フラグが複数の値を取る場合（
--copt=-Da --copt=-Dbや list-type など）は、 Starlark フラグなど）、values = { "flag": "a" }は、"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を参照してください。 valuesdefine_values、constraint_values同じconfig_settingの任意の組み合わせで使用できますが、少なくとも 1 つは使用する必要があります 特定のconfig_settingに対して設定することもできます。
引数
| 属性 | |
|---|---|
name |
名前:必須 このターゲットの一意の名前。 |
constraint_values
|
ターゲット プラットフォームが指定する必要がある constraint_values の最小セット
この config_setting に一致する必要があります。（実行プラットフォームは、
考慮する必要はありません）。プラットフォームに設定されている追加の制約値は無視されます。詳しくは、
構成可能なビルド属性をご覧ください。
2 つの |
define_values
|
辞書: 文字列 ->String;設定不可デフォルトは 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;構成不可デフォルトは values と同じですが、
（）
ユーザー定義のビルドフラグ。
ユーザー定義のフラグはラベルとして参照されますが、 組み込みフラグは任意の文字列として参照されます。 |
values
|
辞書: 文字列 ->String;設定不可デフォルトは このルールは、構成済みのターゲットの構成を
便宜上、構成値はビルドフラグとして指定します（
先行する コマンドラインでフラグが明示的に設定されていない場合は、そのデフォルト値が使用されます。
辞書でキーが複数回出現する場合、最後のインスタンスのみが使用されます。
コマンドラインで複数回設定できるフラグをキーが参照している場合（例:
|
ファイルグループ
ルールのソースを表示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
|
ラベルのリスト。デフォルトは
glob 式の結果は、次の場合に使用するのが一般的です。
|
data
|
ラベルのリスト。デフォルトは
|
output_group
|
String;デフォルトは 「出力グループ」ターゲットの出力アーティファクトのカテゴリで、 適用できます。 |
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
|
String;必須 実行されるクエリ。コマンドラインなどの 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 上の任意の番組を簡単に参照できますが、これによって 非密閉型のコマンドであり、再現できない可能性があります。 1 つのツールのみを実行する必要がある場合は、 run_binary してください。
テストの実行に genrule を使用しないでください。テストとテストには特別な給与が
（キャッシュ ポリシーや環境変数など）の結果を確認できます。通常はテストを実行する必要があり
genrules はビルド完了後にターゲット アーキテクチャで実行されるのに対し、genrules はビルド完了後に実行される
ビルドと exec アーキテクチャです（この 2 つは異なる場合があります）。一般的なユースケースで
sh_test を使用します。
クロスコンパイルの考慮事項
詳しくは、ユーザー マニュアルをご覧ください。 役立ちます。
genrule はビルド中に実行されますが、その出力は多くの場合、デプロイや 説明します。マイクロコントローラの C コードをコンパイルする例を考えてみましょう。コンパイラは C 言語を受け入れます。 マイクロコントローラで実行されるコードを生成できます。生成されたコードは そのビルドに使用された CPU では実行できないが、C コンパイラ（ソースからコンパイルされた場合）は 構成する必要があります
ビルドシステムは exec 構成を使ってビルドを実行するマシンを記述する ビルドの出力先のマシンを記述するためのターゲット構成 指定します。それぞれを構成するオプションが用意されており、 競合を避けるために、対応するファイルを別々のディレクトリに保存してください。
genrules では、依存関係が適切にビルドされていることがビルドシステムによって確認されます。
（必要に応じて）ターゲット構成用に srcs がビルドされます。
tools は exec 構成用にビルドされ、出力は
target 構成のものである必要があります。また、
「つくる」genrule コマンドが対応するツールに渡すことができる変数があります。
genrule で deps 属性を定義しないのは意図的なことです。他の組み込みルールでは、
ルール間で渡される言語依存のメタ情報で、インフラストラクチャの
ただし、genrules ではこのレベルの自動化はできません。genrule の仕組み
実行されています。
特殊なケース
Exec-exec コンパイル: 場合によっては、ビルドシステムで genrules を実行し、
出力はビルド中にも実行できます。たとえば、genrule がカスタム コンパイラを
そのモデルを別の genrule で使用します。1 番目は元のルールに対して
exec 構成を指定しません。他方の genrule でコンパイラが実行されるからです。この例では
ビルドシステムは正しい処理を自動的に行います。つまり、srcs がビルドされ、
ターゲットではなく exec 構成の最初の genrule の outs
できます。詳しくは、ユーザー マニュアルをご覧ください。
JDK とC++ ツール: JDK または C++ コンパイラ スイートのツールを使用するには、ビルドシステム 使用する変数のセットを提供します。「メーカー」変数 表示されます。
Genrule 環境
genrule コマンドは Bash シェルで実行されます。このシェルは、コマンドが失敗したときに失敗するように構成されています。
パイプラインが失敗した場合に set -e -o pipefail を使用します。
ビルドツールは、サニタイズされたプロセス環境で Bash コマンドを実行し、
PATH、PWD、
TMPDIRなど
ビルドの再現性を確保するため、ほとんどの変数はユーザーのシェル
genrule のコマンドには渡されません。ただし、Bazel は
Blaze など）は、ユーザーの PATH 環境変数の値を渡します。
PATH の値を変更すると、Bazel はコマンドを再実行します。
利用可能になります。
genrule コマンドでは、プロセスの接続に使用すること以外は、ネットワーク 子が存在しますが、現在は適用されていません。
ビルドシステムは既存の出力ファイルを自動的に削除するが、必要な親ファイルは作成する ルールを実行する前にディレクトリを 作成する必要があります障害が発生した場合は、出力ファイルも削除されます。
一般的なアドバイス
- genrule によって実行されるツールが決定的かつ密閉型であることを確認してください。書くべき内容ではなく、 タイムスタンプを出力に付ける必要があります。また、セットとマップには安定した順序を使用します。また、 出力への相対ファイルパスのみを書き込み、絶対パスは書き込みません。このルールに従わない場合、 予期しないビルド動作が発生する（Bazel が予想した genrule を再構築しない）原因となり、 キャッシュのパフォーマンスが低下します
- 出力、ツール、ソースに
$(location)を幅広く使用します。これは、 出力ファイルを分離できるため、genrules はハードコードされた 指定することもできます。 - 同一または非常に類似した genrule が Google Cloud で使用される場合に備えて、 複数の場所に存在します。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 がディレクトリ/シンボリック リンクをコピーしない genrules によって作成され、そのディレクトリの依存関係チェックは正常ではありません。
- 他のルールで genrule を参照する場合は、genrule のラベルまたは
各出力ファイルのラベルです。1 つのアプローチの方が読みやすいこともあれば、
その他: 使用ルールの
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 の出力です。代わりに $(SRCS) を使用すると、
明示的な $(location) ディレクティブも使用できます。この例では後者を使用して
見てみましょう。
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 を実行する前にこれらの前提条件が確実にビルドされる
command;元のビルド リクエストと同じ構成を使用してビルドされる。「
これらの前提条件のファイルの名前が、コマンドに
|
outs
|
このルールによって生成されたファイルのリスト。
出力ファイルはパッケージの境界を越えてはいけません。 出力ファイル名はパッケージからの相対名として解釈されます。
genrule コマンドでは、各出力ファイルを所定の場所に作成する必要があります。
ロケーションは、genrule 固有の「Make」を使用して |
cmd
|
String;デフォルトは $(location)
と「Make」を条件とするあります。
cmd_bash、cmd_ps、cmd_bat のフォールバックです。
いずれも該当しない場合は必須です。
コマンドラインの長さがプラットフォームの上限（Linux/macOS では 64 K、Windows では 8 K）を超える場合、
genrule はコマンドをスクリプトに記述し、そのスクリプトを実行して問題を回避します。この
すべての cmd 属性（ |
cmd_bash
|
String;デフォルトは この属性の優先度は |
cmd_bat
|
String;デフォルトは この属性の優先度は
|
cmd_ps
|
String;デフォルトは この属性の優先度は、
Powershell をより使いやすく、エラーが発生しにくくするために、次のコマンドを実行します。 genrule で Powershell コマンドを実行する前に、環境をセットアップする必要があります。
|
executable
|
ブール値設定不可デフォルトは
このフラグを True に設定すると、出力が実行可能ファイルであり、
生成された実行可能ファイルのデータ依存関係の宣言はサポートされていません。 |
local
|
ブール値デフォルトは
True に設定すると、この
これは "local"タグとして指定（ |
message
|
String;デフォルトは
このビルドステップの実行時に出力される進行状況メッセージ。デフォルトでは、
「出力を生成しています」というメッセージが表示されるといった表現が考えられますが、
より具体的なものにします。 |
output_licenses
|
ライセンスの種類デフォルトは common attributes
を参照してください。
|
output_to_bindir
|
ブール値設定不可デフォルトは
True に設定すると、出力ファイルが |
tools
|
ラベルのリスト。デフォルトは
ビルドシステムでは、genrule コマンドを実行する前に、これらの前提条件が確実にビルドされます。
exec パスを使用してビルドされます。
Terraform 構成。これらのツールはビルドの一部として実行されるため、アプリケーションの
個々の
|
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 ファイル。このルールの出力は、定義された ModuleInfo バイナリ proto です。
stardoc_output.proto
（Bazel ソースツリー）
暗黙的な出力ターゲット
name.binaryproto（デフォルト出力）: AModuleInfoバイナリ プロトコル。name.textproto（明示的にリクエストされた場合にのみビルド）: テキストname.binaryprotoの proto バージョン。
警告: このルールの出力形式は、必ずしも安定しているとは限りません。主に Stardoc の内部使用。
引数
| 属性 | |
|---|---|
name |
名前:必須 このターゲットの一意の名前。 |
deps
|
ラベルのリスト。デフォルトは load() で管理される Starlark ファイルをラップするターゲットのリスト。
src。通常の使用では、これらのターゲットは必要です。
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）です。
メイン リポジトリに使用する名前は ドキュメントを生成するときは、この属性を |
symbol_names
|
文字列のリスト。デフォルトは
|
test_suite
ルールのソースを表示test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
test_suite は、「有用」と見なされるテストのセットを定義します。制御します。この
では、プロジェクトで「チェックイン前に実行する必要があるテスト」、「Google の
「プロジェクトのストレステスト」を“すべて小規模なテスト”という
表現を使うこともできます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
|
任意の言語のテストスイートとテスト ターゲットのリスト。
ここでは、言語に関係なく、すべての
|