ルール
エイリアス
ルールソースを表示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" }, )
次のパターンは、x86_64 アーキテクチャと glibc バージョン 2.25 のプラットフォームをターゲットとするビルドに一致します。これは、ラベル //example:glibc_2_25
の constraint_value
が存在することを前提としています。プラットフォームがこれらの 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 フラグなど)を取る場合、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
を参照します。 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 -> 文字列。構成不可。デフォルトは 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
を使用することをおすすめします。後者は、ビルドシステムがディレクトリ内のすべてのファイルを完全に把握していないため、これらのファイルが変更されたときに再ビルドされない可能性があります。filegroup
を glob と組み合わせると、すべてのファイルがビルドシステムに明示的に認識されるようにできます。
例
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 つあります。まず、genquery
では、クエリの推移閉包外のターゲットが出力に影響しないようにスコープを指定する必要があります。次に、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 つ以上のファイルを生成します。
Genrules は、タスクに特定のルールがない場合に使用できる汎用のビルドルールです。たとえば、Bash ワンライナーを実行できます。ただし、C++ ファイルをコンパイルする必要がある場合は、既存の cc_*
ルールに従ってください。すべての面倒な作業はすでに行われています。
genrule では、コマンド引数を解釈するシェルが必要です。PATH で使用可能な任意のプログラムを参照することも簡単ですが、この場合、コマンドは非ヘルメティックになり、再現できない可能性があります。1 つのツールを実行するだけの場合は、代わりに run_binary を使用することを検討してください。
テストの実行に genrule を使用しないでください。テストとテスト結果には、キャッシュ ポリシーや環境変数など、特別な例外があります。通常、テストはビルドの完了後にターゲット アーキテクチャで実行する必要がありますが、genrule はビルド中に実行され、実行アーキテクチャで実行されます(2 つは異なる場合があります)。汎用のテストルールが必要な場合は、sh_test
を使用します。
クロスコンパイルに関する考慮事項
クロスコンパイルの詳細については、ユーザー マニュアルをご覧ください。
genrule はビルド中に実行されますが、その出力はビルド後にデプロイやテストに使用されることがよくあります。マイクロコントローラの C コードをコンパイルする場合を考えてみます。コンパイラは C ソースファイルを受け入れ、マイクロコントローラで実行されるコードを生成します。生成されたコードはビルドに使用された CPU では実行できませんが、C コンパイラ(ソースからコンパイルされた場合)自体は実行する必要があります。
ビルドシステムは exec 構成を使用してビルドを実行するマシンを記述し、ターゲット構成を使用してビルドの出力を実行するマシンを記述します。これらのそれぞれを構成するオプションが提供され、対応するファイルを別々のディレクトリに分離して競合を回避します。
genrules の場合、ビルドシステムは依存関係が適切にビルドされていることを確認します。srcs
は(必要に応じて)ターゲット構成用にビルドされ、tools
は exec 構成用にビルドされ、出力はターゲット構成用のものとみなされます。また、genrule コマンドが対応するツールに渡すことができる
「Make」変数も提供します。
genrule で deps
属性を定義しないという意図があります。他の組み込みルールは、ルール間で渡された言語依存のメタ情報を使用して、依存ルールの処理方法を自動的に決定しますが、genrule ではこのレベルの自動化は不可能です。Genrules は、ファイルと runfile レベルでのみ動作します。
特別なケース
Exec-exec コンパイル: 場合によっては、ビルドシステムで genrules を実行して、ビルド中に出力も実行できるようにする必要があります。たとえば、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)
を広範に使用します。異なる構成の出力ファイルが分離されているため、genrules はハードコードされたパスや絶対パスに依存できません。 - 同一または非常に類似した 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 は、genrules によって作成されたディレクトリ/シンボリック リンク構造をコピーせず、ディレクトリの依存関係チェックは正常に機能しません。
- 他のルールで 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 コマンドでは、各出力ファイルを所定の場所に作成する必要があります。ロケーションは、genrule 固有の「Make」変数( |
cmd
|
文字列。デフォルトは $(location)
と 「Make」変数の置換が適用されます。
cmd_bash 、cmd_ps 、cmd_bat のいずれにも該当しない場合の、これらのフォールバックです。
コマンドライン長がプラットフォームの上限(Linux / macOS では 64,000、Windows では 8,000)を超えると、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
バイナリ proto。name.textproto
(明示的にリクエストされた場合にのみビルドされます):name.binaryproto
のテキスト proto バージョン。
警告: このルールの出力形式は、必ずしも安定しているとは限りません。これは主に 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
|
任意の言語のテストスイートとテストターゲットのリスト。
言語に関係なく、任意の
|