Regras
alias
Exibir origem da regraalias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
A regra alias
cria outro nome para a regra.
A atribuição de alias só funciona para segmentações "regulares". Especificamente, package_group
e test_suite
não podem ter alias.
A atribuição de alias pode ser útil em grandes repositórios em que renomear um destino exigiria alterações em muitos arquivos. Você também pode usar a regra de alias para armazenar uma chamada de função select se quiser reutilizar essa lógica para vários destinos.
A regra de alias tem a própria declaração de visibilidade. Em todos os outros aspectos, ele se comporta como a regra a que se refere (por exemplo, somente testonly no alias é ignorada; no lugar dele, somente teste da regra referenciada é usada) com algumas pequenas exceções:
-
Os testes não serão executados se o alias for mencionado na linha de comando. Para definir um alias
que execute o teste referenciado, use uma regra
test_suite
com um único destino no atributotests
. -
Ao definir grupos de ambiente, não há suporte para os aliases das regras
environment
. Eles também não são compatíveis com a opção de linha de comando--target_environment
.
Exemplos
filegroup( name = "data", srcs = ["data.txt"], ) alias( name = "other", actual = ":data", )
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para o destino. |
actual
|
Label, obrigatório O destino ao qual este alias se refere. Não precisa ser uma regra, também pode ser um arquivo de entrada. |
config_setting
Exibir origem da regraconfig_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
Corresponde a um estado de configuração esperado (expresso como sinalizações de compilação ou restrições de plataforma) para a finalidade de acionar atributos configuráveis. Consulte Selecionar para usar essa regra e Atributos configuráveis para uma visão geral do recurso geral.
Exemplos
O seguinte corresponde a qualquer build que defina --compilation_mode=opt
ou
-c opt
, seja explicitamente na linha de comando ou implicitamente a partir de arquivos .bazelrc:
config_setting( name = "simple", values = {"compilation_mode": "opt"} )
O código a seguir corresponde a qualquer build destinado ao ARM e aplica a definição personalizada
FOO=bar
(por exemplo, bazel build --cpu=arm --define FOO=bar ...
):
config_setting( name = "two_conditions", values = { "cpu": "arm", "define": "FOO=bar" } )
O seguinte corresponde a qualquer build que defina a sinalização definida pelo usuário
--//custom_flags:foo=1
(explicitamente na linha de comando ou implicitamente a partir de arquivos .bazelrc):
config_setting( name = "my_custom_flag_is_set", flag_values = { "//custom_flags:foo": "1" }, )
O código abaixo corresponde a qualquer build destinado a uma plataforma com arquitetura x86_64 e glibc versão 2.25, supondo a existência de um constraint_value
com rótulo //example:glibc_2_25
. Uma plataforma ainda corresponde se definir valores de restrição adicionais além desses dois.
config_setting( name = "64bit_glibc_2_25", constraint_values = [ "@platforms//cpu:x86_64", "//example:glibc_2_25", ] )Em todos esses casos, a configuração poderá mudar no build, por exemplo, se um destino precisar ser criado para uma plataforma diferente da dependente. Isso significa que, mesmo quando um
config_setting
não corresponde aos sinalizadores de linha de comando de nível superior, ele ainda pode corresponder
a alguns destinos de build.
Observações
- Consulte Selecionar para saber o que acontece quando vários
config_setting
s correspondem ao estado de configuração atual. - Para sinalizações compatíveis com formas abreviadas (por exemplo,
--compilation_mode
vs.-c
), as definições devalues
precisam usar o formulário completo. Elas fazem a correspondência automática das invocações que usam um dos formatos. -
Se uma sinalização tiver vários valores (como
--copt=-Da --copt=-Db
ou uma sinalização Starlark do tipo lista),values = { "flag": "a" }
corresponderá se"a"
estiver presente em qualquer lugar da lista real.values = { "myflag": "a,b" }
funciona da mesma maneira: corresponde a--myflag=a --myflag=b
,--myflag=a --myflag=b --myflag=c
,--myflag=a,b
e--myflag=c,b,a
. A semântica exata varia entre as sinalizações. Por exemplo,--copt
não aceita vários valores na mesma instância:--copt=a,b
produz["a,b"]
enquanto--copt=a --copt=b
produz["a", "b"]
. Portanto,values = { "copt": "a,b" }
corresponde ao primeiro, mas não ao segundo. No entanto,--ios_multi_cpus
(para regras da Apple) faz:-ios_multi_cpus=a,b
eios_multi_cpus=a --ios_multi_cpus=b
produzem["a", "b"]
. Verifique as definições de sinalização e teste suas condições com cuidado para confirmar as expectativas exatas. - Se você precisar definir condições que não são modeladas por flags de build integradas, use
flags definidas pelo Starlark. Você também pode usar
--define
, mas isso oferece um suporte mais fraco e não é recomendado. Clique aqui para mais discussões. - Evite repetir definições de
config_setting
idênticas em pacotes diferentes. Em vez disso, faça referência a umconfig_setting
comum definido em um pacote canônico. values
,define_values
econstraint_values
podem ser usados em qualquer combinação no mesmoconfig_setting
, mas pelo menos uma delas precisa ser definida para qualquerconfig_setting
.
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para o destino. |
constraint_values
|
Lista de marcadores; não configurável; o padrão é constraint_values que a plataforma de destino precisa especificar
para corresponder a esse config_setting . A plataforma de execução não é considerada aqui. Quaisquer valores de restrição adicionais que a plataforma tenha são ignorados. Consulte
Atributos de build configuráveis para mais detalhes.
No caso em que dois |
define_values
|
Dicionário: String -> String; nonconfigurable; o padrão é values , mas especificamente para a sinalização --define .
Isso significa que: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) não funciona porque a mesma chave ( config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) corresponde corretamente a
|
flag_values
|
Dicionário: label -> String; nonconfigurable; o padrão é values , mas
para
sinalizações de build definidas pelo usuário.
Esse é um atributo distinto porque as sinalizações definidas pelo usuário são referenciadas como rótulos, enquanto as sinalizações integradas são referenciadas como strings arbitrárias. |
values
|
Dicionário: String -> String; nonconfigurable; o padrão é Essa regra herda a configuração do destino configurado que
o referencia em uma instrução Por conveniência, os valores de configuração são especificados como sinalizações de compilação (sem o Se um sinalizador não for definido explicitamente na linha de comando, o valor padrão será usado.
Se uma chave aparecer várias vezes no dicionário, somente a última instância será usada.
Se uma chave referenciar uma sinalização que pode ser definida várias vezes na linha de comando (por exemplo,
|
grupo de arquivos
Exibir origem da regrafilegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
Use filegroup
para dar um nome conveniente a uma coleção de destinos.
Elas podem então ser referenciadas de outras regras.
É recomendável usar filegroup
em vez de referenciar os diretórios diretamente.
O segundo método não é seguro, já que o sistema de compilação não tem conhecimento total de todos os arquivos
abaixo do diretório. Por isso, ele pode não ser recompilado quando esses arquivos forem alterados. Quando combinado com
glob, filegroup
pode garantir que todos os arquivos sejam
conhecidos explicitamente pelo sistema de build.
Exemplos
Para criar um filegroup
que consiste em dois arquivos de origem, faça o seguinte:
filegroup( name = "mygroup", srcs = [ "a_file.txt", "some/subdirectory/another_file.txt", ], )
Ou use um glob
para encontrar um diretório testdata:
filegroup( name = "exported_testdata", srcs = glob([ "testdata/*.dat", "testdata/logs/**/*.log", ]), )
Para usar essas definições, faça referência ao filegroup
com um rótulo de qualquer regra:
cc_library( name = "my_library", srcs = ["foo.cc"], data = [ "//my_package:exported_testdata", "//my_package:mygroup", ], )
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para o destino. |
srcs
|
Lista de rótulos. O padrão é
É comum usar o resultado de uma expressão glob para o valor do atributo |
data
|
Lista de rótulos. O padrão é
Os destinos nomeados no atributo |
output_group
|
String. O padrão é Um "grupo de saída" é uma categoria de artefatos de saída de um destino, especificado na implementação dessa regra. |
genquery
Exibir origem da regragenquery(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()
executa uma consulta especificada na linguagem de consulta Blaze e salva o resultado em um arquivo.
Para manter o build consistente, a consulta só pode acessar
o fechamento transitivo dos destinos especificados no atributo
scope
. As consultas que violarem essa regra vão falhar durante a execução se strict
não for especificado ou for verdadeiro. Se strict
for falso, os destinos fora do escopo serão ignorados com um aviso. A maneira mais fácil de garantir que isso não aconteça é mencionar os mesmos rótulos no escopo e na expressão de consulta.
A única diferença entre as consultas permitidas aqui e na linha de comando é que as consultas que contêm especificações de destino de caracteres curinga (por exemplo, //pkg:*
ou //pkg:all
) não são permitidas aqui.
Os motivos para isso são duplos: primeiro, porque genquery
precisa
especificar um escopo para evitar destinos fora do fechamento transitivo da
consulta para influenciar a saída e, segundo, porque arquivos BUILD
não são compatíveis com dependências de caracteres curinga (por exemplo, deps=["//a/..."]
não é permitido).
A saída da genquery é ordenada lexicograficamente para impor a saída determinística,
com exceção de --output=graph|minrank|maxrank
ou quando somepath
é usada como a função de nível superior.
O nome do arquivo de saída é o nome da regra.
Exemplos
Este exemplo grava a lista dos rótulos no fechamento transitivo do destino especificado em um arquivo.
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para o destino. |
compressed_output
|
Booleano. O padrão é True , a saída da consulta será gravada no formato de arquivo GZIP. Essa configuração pode ser usada para evitar picos no uso de memória do Bazel quando a saída da consulta é grande. O Bazel
já compacta internamente saídas de consulta com mais de 220 bytes, seja qual for
o valor dessa configuração. Portanto, definir como True pode não reduzir o heap
retido. No entanto, ela permite que o Bazel ignore a descompactação ao gravar o arquivo de saída, o que pode consumir muita memória.
|
expression
|
String, obrigatório A consulta a ser executada. Ao contrário da linha de comando e de outros locais nos arquivos BUILD, os rótulos são resolvidos em relação ao diretório raiz do espaço de trabalho. Por exemplo, o rótulo:b neste atributo no arquivo a/BUILD se referirá ao
destino //:b .
|
opts
|
Lista de strings. O padrão é bazel query . Algumas opções de consulta não são permitidas aqui: --keep_going , --query_file , --universe_scope , --order_results e --order_output . As opções não especificadas aqui
terão os valores padrão, assim como na linha de comando de bazel query .
|
scope
|
Lista de rótulos, obrigatório O escopo da consulta. A consulta não tem permissão para tocar em áreas fora do fechamento transitivo delas. |
strict
|
Booleano. O padrão é |
genrule
Exibir origem da regragenrule(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)
Um genrule
gera um ou mais arquivos usando um comando Bash definido pelo usuário.
Regras gerais são regras de build genéricas que você pode usar se não houver uma regra específica para a tarefa.
Por exemplo, você poderia executar um resumo do Bash. No entanto, se você precisar compilar arquivos C++, siga as regras cc_*
existentes, porque todo o trabalho pesado já foi feito para você.
Observe que a genrule exige um shell para interpretar o argumento do comando. Também é fácil referenciar programas arbitrários disponíveis no PATH. No entanto, isso torna o comando não hermético e pode não ser reproduzível. Se você precisa executar apenas uma ferramenta, use run_binary.
Não use uma regra geral para executar testes. Há dispensas especiais para testes e resultados de testes, incluindo políticas de armazenamento em cache e variáveis de ambiente. Os testes geralmente precisam ser executados
após a conclusão do build e na arquitetura de destino, enquanto as regras gerais são executadas durante
a compilação e na arquitetura de execução (as duas podem ser diferentes). Se você precisar de uma regra de teste de uso geral, use sh_test
.
Considerações sobre compilação cruzada
Consulte o manual do usuário para saber mais sobre a compilação cruzada.
Embora as regras gerais sejam executadas durante um build, as saídas delas geralmente são usadas após a build, para implantação ou teste. Considere o exemplo de compilação de código C para um microcontrolador: o compilador aceita arquivos de origem em C e gera um código que é executado em um microcontrolador. Obviamente, o código gerado não pode ser executado na CPU usada para criá-lo, mas o compilador C (se compilado da origem) precisa fazer isso.
O sistema de build usa a configuração "exec" para descrever as máquinas em que o build é executado e a configuração de destino para descrever as máquinas em que a saída do build deve ser executada. Ele oferece opções para configurar cada um deles e separa os arquivos correspondentes em diretórios diferentes para evitar conflitos.
Para as regras gerais, o sistema de build garante que as dependências sejam criadas corretamente:
srcs
são criados (se necessário) para a configuração target,
tools
são criados para a configuração exec e a saída é considerada
para a configuração target. Ela também fornece
variáveis "Make" que os comandos genrule podem passar para as ferramentas correspondentes.
É intencional que a genrule não defina nenhum atributo deps
: outras regras integradas usam
metainformações dependentes da linguagem transmitidas entre as regras para determinar automaticamente como
lidar com regras dependentes, mas esse nível de automação não é possível para regras gerais. As regras gerais funcionam
puramente no nível do arquivo e dos arquivos de execução.
Casos especiais
Compilação Exec-exec: em alguns casos, o sistema de compilação precisa executar regras gerais para que a
saída também possa ser executada durante a compilação. Se, por exemplo, uma regra geral criar um compilador personalizado
que é usado posteriormente por outra regra geral, o primeiro precisa produzir a saída para a
configuração "exec", porque é nele que o compilador será executado na outra regra geral. Nesse caso,
o sistema de build faz a coisa certa automaticamente: ele cria o srcs
e
outs
da primeira regra de geração para a configuração "exec" em vez da
configuração de destino. Consulte o manual do usuário para mais informações.
Ferramentas JDK e C++: para usar uma ferramenta do JDK ou do pacote de compilador C++, o sistema de compilação fornece um conjunto de variáveis para uso. Consulte a variável"Make" para mais detalhes.
Ambiente de regra geral
O comando genrule é executado por um shell Bash configurado para falhar quando um comando ou um pipeline falha, usando set -e -o pipefail
.
A ferramenta de build executa o comando Bash em um ambiente de processo limpo que
define apenas as variáveis principais, como PATH
, PWD
, TMPDIR
e algumas outras.
Para garantir que as builds sejam reproduzíveis, a maioria das variáveis definidas no ambiente shell
do usuário não são passadas para o comando da genrule. No entanto, o Bazel (mas não o
Blaze) transmite o valor da variável de ambiente PATH
do usuário.
Qualquer alteração no valor de PATH
fará com que o Bazel execute novamente o comando
no próximo build.
Um comando genrule não pode acessar a rede, exceto para conectar processos que são filhos do próprio comando, embora isso não seja aplicado no momento.
O sistema de compilação exclui automaticamente todos os arquivos de saída existentes, mas cria todos os diretórios pais necessários antes de executar uma regra geral. Ele também remove todos os arquivos de saída em caso de falha.
Recomendação geral
- Garantir que as ferramentas executadas por uma regra geral sejam determinísticas e herméticas. Eles não devem gravar carimbos de data/hora na saída e precisam usar a ordem estável para conjuntos e mapas, bem como gravar apenas caminhos de arquivo relativos para a saída, e não caminhos absolutos. Não seguir essa regra vai causar um comportamento de build inesperado (o Bazel não vai recriar uma regra geral que você imaginava) e prejudicará o desempenho do cache.
- Use
$(location)
extensivamente para saídas, ferramentas e fontes. Devido à segregação dos arquivos de saída para diferentes configurações, as regras gerais não podem depender de caminhos absolutos e/ou codificados. - Escreva uma macro Starlark comum caso regras gerais iguais ou muito semelhantes sejam usadas em vários locais. Se a regra geral for complexa, considere implementá-la em um script ou como uma regra Starlark. Isso melhora a legibilidade e a capacidade de teste.
- Verifique se o código de saída indica corretamente o sucesso ou a falha da regra geral.
- Não grave mensagens informativas em stdout ou stderr. Embora útil para depuração, isso pode facilmente se tornar ruído. Uma regra geral bem-sucedida precisa ser silenciosa. Por outro lado, uma regra geral com falha emite boas mensagens de erro.
$$
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)
.- Evite criar links simbólicos e diretórios. O Bazel não copia a estrutura de diretório/link simbólico criada pelas regras gerais, e a verificação de dependência dos diretórios não é sonora.
- Ao fazer referência à regra geral em outras regras, é possível usar o rótulo dela ou os
rótulos de arquivos de saída individuais. Às vezes, uma abordagem é mais legível, às vezes a outra: referenciar saídas por nome no
srcs
de uma regra de consumo evita a coleta não intencional de outras saídas da regra geral, mas pode ser entediante se ela produzir muitas saídas.
Exemplos
Este exemplo gera foo.h
. Não há origens, porque o comando não recebe
nenhuma entrada. O "binário" executado pelo comando é um script perl no mesmo pacote da regra geral.
genrule( name = "foo", srcs = [], outs = ["foo.h"], cmd = "./$(location create_foo.pl) > \"$@\"", tools = ["create_foo.pl"], )
O exemplo a seguir mostra como usar um filegroup
e as saídas de outro genrule
. O uso de $(SRCS)
em vez de diretivas $(location)
explícitas também funciona. Este exemplo usa a última para fins de demonstração.
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) > $@", )
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para o destino. É possível se referir a essa regra pelo nome na seção srcs ou deps de outras regras
BUILD . Se a regra gerar arquivos de origem, use o
atributo srcs .
|
srcs
|
Lista de rótulos. O padrão é
Esse atributo não é adequado para listar ferramentas executadas pelo
O sistema de build garante que esses pré-requisitos sejam criados antes de executar o comando
genrule. Eles são criados usando a mesma configuração da solicitação de build original. Os
nomes dos arquivos desses pré-requisitos estão disponíveis para o comando como uma
lista separada por espaços em |
outs
|
Lista de nomes de arquivos; não configurável; obrigatório Uma lista de arquivos gerados por esta regra.Os arquivos de saída não podem ultrapassar os limites do pacote. Os nomes de arquivos de saída são interpretados como relativos ao pacote.
Se a sinalização
Espera-se que o comando genrule crie cada arquivo de saída em um local predeterminado.
O local está disponível em |
cmd
|
String. O padrão é $(location)
e Make.
cmd_bash , cmd_ps e cmd_bat ,
se nenhum deles for aplicável.
Se o comprimento da linha de comando exceder o limite da plataforma (64 mil no Linux/macOS, 8 mil no Windows),
o genrule gravará o comando em um script e executará esse script para solucionar o problema. Isso
se aplica a todos os atributos cmd ( |
cmd_bash
|
String. O padrão é Este atributo tem prioridade maior que |
cmd_bat
|
String. O padrão é Esse atributo tem prioridade mais alta do que
|
cmd_ps
|
String. O padrão é Esse atributo tem prioridade mais alta que
Para tornar o PowerShell mais fácil de usar e menos propenso a erros, executamos os seguintes comandos para configurar o ambiente antes de executar o comando do PowerShell na genrule.
|
executable
|
Booleano; não configurável; o padrão é
Definir essa flag como "True" significa que a saída é um arquivo executável que pode ser executada usando o
comando Não é possível declarar dependências de dados para o executável gerado. |
local
|
Booleano. O padrão é
Se definida como "True", essa opção forçará este
Isso equivale a fornecer "local" como uma tag ( |
message
|
String. O padrão é
Uma mensagem de progresso que será impressa enquanto essa etapa de build é executada. Por padrão, a mensagem é "Gerando output" (ou algo igualmente sem graça), mas você pode fornecer uma mais específica. Use esse atributo em vez de |
output_licenses
|
Tipo de licença. O padrão é common attributes
.
|
output_to_bindir
|
Booleano; não configurável; o padrão é
Se definida como verdadeira, essa opção fará com que os arquivos de saída sejam gravados no diretório |
tools
|
Lista de rótulos. O padrão é
O sistema de build garante que esses pré-requisitos sejam criados antes da execução do comando genrule.
Eles são criados usando a configuração
exec, já que essas ferramentas são executadas como parte do build. O caminho de um
Qualquer |
starlark_doc_extract
Exibir origem da regrastarlark_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)
O starlark_doc_extract()
extrai a documentação de regras, funções (incluindo
macros), aspectos e provedores definidos ou reexportados em determinado arquivo .bzl
ou
.scl
. A saída dessa regra é um .proto binário ModuleInfo
, conforme definido
em
stardoc_output.proto,
na árvore de origem do Bazel.
Destinos de saída implícitos
name.binaryproto
(a saída padrão): um protótipo binárioModuleInfo
.name.textproto
(criado apenas se solicitado explicitamente): a versão .proto de texto dename.binaryproto
.
Aviso: não há garantia de que o formato de saída dessa regra seja estável. Ele se destina principalmente ao uso interno pelo Stardoc.
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para o destino. |
deps
|
Lista de rótulos. O padrão é load() adicionados por
src . Em uso normal, esses destinos devem ser destinos bzl_library , mas a regra starlark_doc_extract não impõe isso e aceita qualquer destino que forneça arquivos Starlark no DefaultInfo .
Os arquivos Starlark encapsulados precisam estar na árvore de origem. O Bazel não pode gerar arquivos gerados por |
src
|
Label, obrigatório Um arquivo Starlark do qual extrair a documentação.Observe que ele precisa estar na árvore de origem. O Bazel não pode |
render_main_repo_name
|
Booleano. O padrão é //foo:bar.bzl é emitido como
@main_repo_name//foo:bar.bzl .
O nome a ser usado para o repositório principal é obtido de Esse atributo precisa ser definido como |
symbol_names
|
Lista de strings. O padrão é
|
test_suite
Exibir origem da regratest_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
Uma test_suite
define um conjunto de testes que são considerados "úteis" para humanos. Isso
permite que os projetos definam conjuntos de testes, como "testes que você precisa executar antes do check-in", "testes
de estresse do nosso projeto" ou "todos os testes pequenos". O comando blaze test
respeita esse tipo
de organização: para uma invocação como blaze test //some/test:suite
, o Blaze primeiro
enumera todos os destinos de teste incluídos transitivamente pelo destino //some/test:suite
(chamamos
isso de "expansão test_suite"). Em seguida, o Blaze cria e testa esses destinos.
Exemplos
Um pacote de testes para executar todos os testes pequenos no pacote atual.
test_suite( name = "small_tests", tags = ["small"], )
Um pacote que executa um conjunto específico de testes:
test_suite( name = "smoke_tests", tests = [ "system_unittest", "public_api_unittest", ], )
Um pacote para executar todos os testes não instáveis no pacote atual.
test_suite( name = "non_flaky_test", tags = ["-flaky"], )
Argumentos
Atributos | |
---|---|
name |
Nome, obrigatório Um nome exclusivo para o destino. |
tags
|
Lista de strings; não configurável; o padrão é As tags que começam com um caractere "-" são consideradas negativas. O caractere "-" anterior não é considerado parte da tag. Portanto, uma tag de pacote "-small" corresponde ao tamanho "pequeno" de um teste. Todas as outras são consideradas tags positivas. Para deixar as tags positivas mais explícitas, elas também podem começar com o caractere "+", que não será avaliado como parte do texto. Isso apenas torna a distinção positiva e negativa mais fácil de ler. Serão incluídas no pacote de testes somente as regras de teste que corresponderem a todas as tags positivas e a nenhuma das tags negativas. Isso não significa que a verificação de erros de dependências em testes filtrados seja ignorada. As dependências em testes ignorados ainda precisam ser legais (por exemplo, não bloqueadas por restrições de visibilidade).
A palavra-chave de tag
O
Se você precisar de um |
tests
|
Lista de marcadores; não configurável; o padrão é
Qualquer
Se o atributo |