규칙
alias
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
alias
규칙은 규칙을 참조할 수 있는 다른 이름을 만듭니다.
앨리어싱은 '일반' 타겟에서만 작동합니다. 특히 package_group
와 test_suite
는 별칭을 지정할 수 없습니다.
별칭 규칙에는 자체 공개 상태 선언이 있습니다. 다른 모든 면에서 이 클래스는 참조하는 규칙처럼 동작합니다 (예: 별칭의 testonly는 무시되고 참조된 규칙의 testonly-ness가 대신 사용됨). 단, 다음과 같은 사소한 예외가 있습니다.
-
명령줄에서 별칭이 언급된 경우 테스트가 실행되지 않습니다. 참조된 테스트를 실행하는 별칭을 정의하려면
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)
구성 가능한 속성을 트리거할 목적으로 예상되는 구성 상태 (빌드 플래그 또는 플랫폼 제약조건으로 표현됨)와 일치합니다. 이 규칙을 사용하는 방법은 선택을, 일반 기능의 개요는 구성 가능한 속성을 참고하세요.
예
다음은 --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
이 있다고 가정합니다. 플랫폼은 이 두 개 이외의 추가 제약조건 값을 정의하는 경우 여전히 일치합니다.
config_setting( name = "64bit_glibc_2_25", constraint_values = [ "@platforms//cpu:x86_64", "//example:glibc_2_25", ] )대상이 종속 항목과 다른 플랫폼에 대해 빌드되어야 하는 경우와 같이 이 모든 경우에 빌드 내에서 구성이 변경될 수 있습니다. 즉,
config_setting
이 최상위 명령줄 플래그와 일치하지 않더라도 일부 빌드 타겟과 일치할 수 있습니다.
Notes
- 여러
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
에 하나 이상이 설정되어야 합니다.
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
constraint_values
|
config_setting 와 일치하기 위해 타겟 플랫폼이 지정해야 하는 최소 constraint_values 집합입니다. 여기서는 실행 플랫폼을 고려하지 않습니다. 플랫폼이 추가한 추가 제약 조건 값은 무시됩니다. 자세한 내용은
구성 가능한 빌드 속성을 참조하세요.
두 개의 |
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
|
values 와 동일하지만
사용자 정의 빌드 플래그에 적용됩니다.
사용자 정의 플래그는 라벨로 참조되는 반면 내장 플래그는 임의의 문자열로 참조되기 때문에 이 속성은 고유한 속성입니다. |
values
|
이 규칙은 편의상 구성 값은 앞의 명령줄에서 플래그를 명시적으로 설정하지 않으면 기본값이 사용됩니다.
키가 사전에 여러 번 나타날 경우 마지막 인스턴스만 사용됩니다.
키가 명령줄에서 여러 번 설정할 수 있는 플래그 (예:
|
파일 그룹
filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
filegroup
을 사용하여 타겟 컬렉션에 편리한 이름을 지정합니다.
그런 다음 다른 규칙에서 이를 참조할 수 있습니다.
디렉터리를 직접 참조하는 대신 filegroup
를 사용하는 것이 좋습니다.
빌드 시스템이 디렉터리 아래의 모든 파일을 완전히 알지 못하기 때문에 후자는 적절하지 않으며 이러한 파일이 변경될 때 다시 빌드되지 않을 수 있습니다. glob와 결합되면 filegroup
는 모든 파일이 빌드 시스템에 명시적으로 알려지도록 할 수 있습니다.
예
두 개의 소스 파일로 구성된 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
|
'출력 그룹'은 규칙의 구현에 지정된 대상의 출력 아티팩트 카테고리입니다. |
Genquery
genquery(name, deps, data, compatible_with, 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
)이 포함된 쿼리는 허용되지 않는다는 것입니다.
그 이유는 두 가지입니다.첫째, genquery
가 쿼리의 전이적 닫힘 외부에 있는 대상이 출력에 영향을 미치지 않도록 범위를 지정해야 하기 때문입니다. 두 번째는 BUILD
파일이 와일드 카드 종속 항목을 지원하지 않기 때문입니다 (예: deps=["//a/..."]
는 허용되지 않음).
Genquery의 출력은 확정적 출력을 적용하기 위해 --order_output=full
를 사용하여 정렬됩니다.
출력 파일의 이름은 규칙의 이름입니다.
예
이 예에서는 지정된 타겟의 전이 닫힘에 있는 라벨 목록을 파일에 씁니다.
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
expression
|
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, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
genrule
는 사용자 정의 Bash 명령어를 사용하여 하나 이상의 파일을 생성합니다.
Genrule은 작업에 대한 특정 규칙이 없는 경우 사용할 수 있는 일반적인 빌드 규칙입니다.
예를 들어 Bash 한 줄을 실행할 수 있습니다. 하지만 C++ 파일을 컴파일해야 한다면 기존 cc_*
규칙을 따르세요. 어려운 작업이 모두 이미 완료되었기 때문입니다.
테스트 실행에 genrule을 사용하지 않습니다. 캐싱 정책 및 환경 변수를 포함하여 테스트 및 테스트 결과에 대한 특별한 분배가 있습니다. 테스트는 일반적으로 빌드가 완료된 후 타겟 아키텍처에서 실행해야 하는 반면, genrule은 빌드 중에 및 호스트 아키텍처에서 실행됩니다 (둘은 다를 수 있음). 범용 테스트 규칙이 필요하면 sh_test
를 사용하세요.
크로스 컴파일 고려사항
크로스 컴파일에 대한 자세한 내용은 사용자 매뉴얼을 참조하세요.
genrule이 빌드 중에 실행되지만 출력은 빌드 후에 배포 또는 테스트를 위해 사용되는 경우가 많습니다. 마이크로 컨트롤러용으로 C 코드를 컴파일하는 예를 생각해 보세요. 컴파일러는 C 소스 파일을 받아 마이크로 컨트롤러에서 실행되는 코드를 생성합니다. 생성된 코드는 코드를 빌드하는 데 사용된 CPU에서 실행될 수 없지만 C 컴파일러 (소스에서 컴파일된 경우) 자체는 실행해야 합니다.
빌드 시스템은 호스트 구성을 사용하여 빌드가 실행되는 머신을 설명하고 타겟 구성을 사용하여 빌드의 출력이 실행될 머신을 설명합니다. 각각을 구성하는 옵션을 제공하고 충돌을 방지하기 위해 해당 파일을 별도의 디렉터리로 분리합니다.
genrules의 경우 빌드 시스템은 종속 항목이 적절하게 빌드되도록 합니다. 필요한 경우 srcs
는 target 구성에 대해 빌드되고 tools
는 host 구성에 대해 빌드되며 출력은 target 구성용으로 간주됩니다. 또한 genrule 명령어가 해당 도구에 전달할 수 있는
'Make' 변수를 제공합니다.
genrule은 deps
속성을 정의하지 않도록 의도된 것입니다. 다른 기본 규칙은 규칙 사이에 전달된 언어별 메타 정보를 사용하여 종속 규칙을 처리하는 방법을 자동으로 결정하지만 genrules에는 이러한 수준의 자동화가 불가능합니다. Genrules는 파일 및 실행 파일 수준에서만 작동합니다.
특수 사례
호스트-호스트 컴파일: 경우에 따라 빌드 시스템에서 출력도 실행되게 하려면 genrule을 실행해야 합니다. 예를 들어 genrule이 이후에 다른 genrule에 의해 사용되는 커스텀 컴파일러를 빌드하는 경우 첫 번째 genrule이 호스트 구성에 대한 출력을 생성해야 합니다. 이 곳에서 컴파일러가 다른 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은 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: 64K, Windows: 8K)을 초과하면 genrule이 스크립트에 명령어를 작성하고 해당 스크립트를 실행하여 문제를 해결합니다. 이는 모든 cmd 속성 ( |
cmd_bash
|
이 속성은 |
cmd_bat
|
이 속성은
|
cmd_ps
|
이 속성은
Powershell을 더 쉽게 사용하고 오류를 줄이기 위해 genrule에서 Powershell 명령어를 실행하기 전에 다음 명령어를 실행하여 환경을 설정합니다.
|
exec_tools
|
tools 속성과 동일하게 동작하지만, 이러한 종속 항목이 호스트 구성 대신 규칙의 실행 플랫폼에 구성된다는 점이 다릅니다.
즉, exec_tools 의 종속 항목에는 tools 의 종속 항목과 동일한 제한사항이 적용되지 않습니다. 특히 자체 전이 종속 항목에 호스트 구성을 사용할 필요가 없습니다. 자세한 내용은 tools 를 참고하세요.
Blaze팀은 |
executable
|
이 플래그를 True로 설정하면 출력이 실행 파일이며 생성된 실행 파일의 데이터 종속 항목 선언은 지원되지 않습니다. |
local
|
True로 설정하면 이 옵션에서는 이
이는 'local'을 태그 ( |
message
|
이 빌드 단계가 실행될 때 출력될 진행률 메시지입니다. 기본적으로 메시지는 '출력 생성 중' (또는 똑같이 단조로운 메시지)이지만 더 구체적인 메시지를 제공할 수도 있습니다. |
output_licenses
|
common attributes
을 참고하세요.
|
output_to_bindir
|
이 옵션을 True로 설정하면 출력 파일이 |
tools
|
빌드 시스템은 genrule 명령어를 실행하기 전에 이러한 기본 요건이 빌드되도록 합니다. 이러한 도구는 빌드의 일부로 실행되므로 host 구성을 사용하여 빌드됩니다. 개별
|
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
|
여기서는 언어와 무관하게 모든
|