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 que pode ser usado para se referir a uma regra.
A atribuição de alias só funciona para segmentações "regulares". Especificamente, package_group
e test_suite não podem ter um alias.
O uso de pseudônimos pode ser útil em repositórios grandes, em que renomear um destino exigiria mudanças 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 teste no alias é ignorado. No lugar, ele se comporta como somente teste da regra referenciada, 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_suitecom um único destino no atributotests. -
Ao definir grupos de ambiente, os aliases para regras
environmentnão são aceitos. 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
|
Rótulo: obrigatório O destino a que o alias se refere. Não precisa ser uma regra, também pode ser um arquivo de entrada. |
config_setting
Acessar a 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 saber como usar essa regra e Atributos configuráveis para ter uma visão geral do recurso geral.
Exemplos
O exemplo a seguir corresponde a qualquer build que defina --compilation_mode=opt ou
-c opt (explicitamente na linha de comando ou implicitamente nos arquivos .bazelrc):
config_setting(
name = "simple",
values = {"compilation_mode": "opt"}
)
O exemplo a seguir corresponde a qualquer build destinado a 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 exemplo a seguir corresponde a qualquer build que defina a
flag definida pelo usuário
--//custom_flags:foo=1 (explicitamente na linha de comando ou implicitamente nos
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 vai corresponder se definir outros valores de restrição 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, é possível que a configuração mude no build, por exemplo, se
um destino precisar ser criado para uma plataforma diferente da dependência. Isso significa que, mesmo quando um
config_setting não corresponder às flags de linha de comando de nível superior, ele ainda poderá corresponder
a alguns destinos de build.
Observações
- Consulte selecionar para saber o que acontece quando vários
config_settings correspondem ao estado de configuração atual. - Para sinalizações compatíveis com formas abreviadas (por exemplo,
--compilation_modevs.-c), as definições devaluesprecisam usar o formulário completo. Elas correspondem automaticamente a invocações usando qualquer um dos formatos. -
Se uma flag tiver vários valores (como
--copt=-Da --copt=-Dbou uma flag do tipo lista Starlark),values = { "flag": "a" }vai corresponder se"a"estiver presente em qualquer lugar da lista.values = { "myflag": "a,b" }funciona da mesma maneira: corresponde a--myflag=a --myflag=b,--myflag=a --myflag=b --myflag=c,--myflag=a,be--myflag=c,b,a. A semântica exata varia entre as flags. Por exemplo,--coptnão oferece suporte a vários valores na mesma instância:--copt=a,bproduz["a,b"], enquanto--copt=a --copt=bproduz["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,beios_multi_cpus=a --ios_multi_cpus=bproduzem["a", "b"]. Verifique as definições de sinalizador e teste suas condições com cuidado para verificar as expectativas exatas. - Se você precisar definir condições que não sejam modeladas por flags de build integradas, use
Flags definidas pelo Starlark. Você também pode usar
--define, mas isso oferece suporte mais fraco e não é recomendado. Consulte este link para mais informações. - Evite repetir definições idênticas de
config_settingem pacotes diferentes. Em vez disso, faça referência a umconfig_settingcomum definido em um pacote canônico. values,define_valueseconstraint_valuespodem ser usados em qualquer combinação no mesmoconfig_setting, mas pelo menos um precisa ser definido para qualquerconfig_setting.
Argumentos
| Atributos | |
|---|---|
name |
Nome: obrigatório Um nome exclusivo para essa segmentação. |
constraint_values
|
Lista de rótulos; 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. Todos os valores de restrição adicionais que a plataforma tem são ignorados. Consulte
Atributos de build configuráveis para mais detalhes.
Quando dois |
define_values
|
Dicionário: String -> String; nonconfigurable; o padrão é values, mas especificamente para a sinalização --define.
Isso significa:
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 O |
flag_values
|
Dicionário: label -> String; nonconfigurable; o padrão é values, mas
para
flags de build definidas pelo usuário.
Esse é um atributo distinto porque as flags definidas pelo usuário são referenciadas como rótulos, enquanto as flags 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 Para maior conveniência, os valores de configuração são especificados como flags de build (sem
Se uma flag não for definida explicitamente na linha de comando, o valor padrão dela 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
Acessar a 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 ser referenciadas em outras regras.
Recomendamos o uso de filegroup em vez de referenciar diretórios diretamente.
O segundo não é confiável, porque o sistema de build não tem conhecimento completo de todos os arquivos
abaixo do diretório. Portanto, ele pode não ser recriado quando esses arquivos mudarem. Quando combinado com
glob, filegroup pode garantir que todos os arquivos sejam
conhecidos explicitamente pelo sistema de build.
Exemplos
Para criar um filegroup composto por 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 criar um diretório de dados de teste:
filegroup(
name = "exported_testdata",
srcs = glob([
"testdata/*.dat",
"testdata/logs/**/*.log",
]),
)
Para usar essas definições, faça referência a 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
Acessar a 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 a consistência do build, a consulta só pode visitar
a clausura transitiva das metas especificadas no atributo
scope. As consultas que violam essa regra vão falhar durante a execução se
strict for indefinido ou 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 que na expressão de consulta.
A única diferença entre as consultas permitidas aqui e na linha de comando é que as consultas com especificações de destino de caractere curinga (por exemplo, //pkg:* ou //pkg:all) não são permitidas aqui.
Isso acontece por dois motivos: primeiro, porque genquery precisa especificar um escopo para impedir que os destinos fora do fechamento transitivo da consulta influenciem a saída. Em segundo lugar, porque os arquivos BUILD não são compatíveis com dependências de curinga (por exemplo, deps=["//a/..."] não é permitido).
A saída de genquery é ordenada lexicograficamente para aplicar a saída determinística,
com exceção de --output=graph|minrank|maxrank ou quando somepath
é usado 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 de identificadores 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 as saídas de consulta maiores que 220 bytes, independentemente
do valor dessa configuração. Portanto, definir esse valor como True pode não reduzir a pilha
retida. No entanto, ele permite que o Bazel pule a descompactação ao gravar o arquivo de saída,
que pode exigir muita memória.
|
expression
|
String; obrigatório A consulta a ser executada. Ao contrário da linha de comando e de outros lugares nos arquivos BUILD, os rótulos aqui 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 refere 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 pode tocar em destinos fora do fechamento transitivo desses destinos. |
strict
|
Booleano; o padrão é |
genrule
Acessar a 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.
As regras genéricas de build podem ser usadas se não houver uma regra específica para a tarefa.
Por exemplo, você pode executar um comando Bash de uma linha. No entanto, se você precisar compilar arquivos C++, siga
as regras cc_* atuais, porque todo o trabalho pesado já foi feito
para você.
O genrule exige um shell para interpretar o argumento do comando. Também é fácil fazer referência a programas arbitrários disponíveis no PATH, mas isso faz com que o comando não seja hermético e possa não ser reproduzível. Se você precisar executar apenas uma ferramenta, use run_binary em vez disso.
Não use uma regra de geração para executar testes. Há dispensas especiais para testes e resultados
de teste, incluindo políticas de armazenamento em cache e variáveis de ambiente. Os testes geralmente precisam ser executados
depois que o build é concluído e na arquitetura de destino, enquanto as regras de geração são executadas durante
o build e na arquitetura de execução (as duas podem ser diferentes). Se você precisar de uma regra de teste
geral, use sh_test.
Considerações sobre a compilação cruzada
Consulte o manual do usuário para mais informações sobre a compilação cruzada.
Embora as regras de geração sejam executadas durante um build, as saídas delas são frequentemente usadas após o 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 C e gera 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 de execução 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 precisa ser executada. Ele oferece opções para configurar cada um deles e separa os arquivos correspondentes em diretórios separados para evitar conflitos.
Para regras de geração, o sistema de build garante que as dependências sejam criadas de maneira adequada:
srcs são criadas (se necessário) para a configuração target,
tools são criadas 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. O Genrules funciona
apenas no nível de arquivos e runfiles.
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 é nesse local 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 Variável "Criar" para mais detalhes.
Ambiente Genrule
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 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 deve 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 build exclui automaticamente todos os arquivos de saída existentes, mas cria todos os diretórios principais necessários antes de executar uma genrule. Ele também remove todos os arquivos de saída em caso de falha.
Conselhos gerais
- Garanta que as ferramentas executadas por uma regra geral sejam determinísticas e herméticas. Não é necessário gravar carimbos de data/hora na saída. Use ordenação estável para conjuntos e mapas, além de gravar apenas caminhos de arquivo relativos na saída, sem caminhos absolutos. Não seguir essa regra vai levar a um comportamento de build inesperado (o Bazel não recria uma genrule que você achava que ele recria) e vai degradar a performance do cache.
- Use
$(location)extensivamente para saídas, ferramentas e fontes. Devido à segregação de arquivos de saída para diferentes configurações, o genrules não pode usar caminhos fixos e/ou absolutos. - Escreva uma macro Starlark comum caso as mesmas regras de geração ou regras muito semelhantes sejam usadas em vários lugares. 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 genrule.
- Não grave mensagens informativas no stdout ou stderr. Embora seja útil para depuração, isso pode se tornar um ruído. Uma genrule bem-sucedida precisa ser silenciosa. Por outro lado, uma genrule com falha deve emitir 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 à genrule em outras regras, você pode usar o rótulo da genrule 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
srcsde uma regra de consumo evita a seleção 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á fontes porque o comando não recebe
nenhuma entrada. O "binário" executado pelo comando é um script Perl no mesmo pacote que a genrule.
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 o último 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. Você pode 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 da execução do 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 cruzar os limites do pacote. Os nomes de arquivos de saída são interpretados como relativos ao pacote.
Se a sinalização
O comando genrule precisa criar cada arquivo de saída em um local predeterminado.
O local está disponível em |
cmd
|
String; o padrão é $(location)
e variável"Make".
cmd_bash, cmd_ps e cmd_bat,
se nenhuma delas for aplicável.
Se o comprimento da linha de comando exceder o limite da plataforma (64K no Linux/macOS, 8K no Windows),
o genrule vai gravar o comando em um script e executar esse script para contornar o problema. Isso
se aplica a todos os atributos cmd ( |
cmd_bash
|
String. O padrão é Esse atributo tem prioridade maior que |
cmd_bat
|
String; o padrão é Esse atributo tem prioridade maior que
|
cmd_ps
|
String; o padrão é Esse atributo tem prioridade mais alta que
Para facilitar o uso do Powershell e reduzir a probabilidade de erros, executamos os seguintes comandos para configurar o ambiente antes de executar o comando do Powershell no genrule.
|
executable
|
Booleano; não configurável; o padrão é
Definir essa flag como "true" significa que a saída é um arquivo executável e 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 é equivalente a fornecer "local" como uma tag ( |
message
|
String; o padrão é
Uma mensagem de progresso que será mostrada quando esta etapa de build for executada. Por padrão, a
mensagem é "Gerando saída" (ou algo igualmente genérico), 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 "True", essa opção faz 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
alvo
Qualquer |
starlark_doc_extract
Acessar a 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)
starlark_doc_extract() extrai a documentação de regras, funções (incluindo
macros), aspectos e provedores definidos ou reexportados em um 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.
Alvos 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 é destinado principalmente ao uso interno da Stardoc.
Argumentos
| Atributos | |
|---|---|
name |
Nome: obrigatório Um nome exclusivo para essa segmentação. |
deps
|
Lista de rótulos; o padrão é load()-ed 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
|
src
|
Rótulo: obrigatório Um arquivo Starlark do qual extrair a documentação.Ele precisa ser um arquivo na árvore de origem. O Bazel não pode gerar arquivos |
render_main_repo_name
|
Booleano; o padrão é //foo:bar.bzl será emitido como
@main_repo_name//foo:bar.bzl.
O nome a ser usado para o repositório principal é extraído de Esse atributo precisa ser definido como |
symbol_names
|
Lista de strings. O padrão é
|
test_suite
Acessar a origem da regratest_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
Um 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 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 conjunto de testes para executar todos os pequenos testes no pacote atual.
test_suite(
name = "small_tests",
tags = ["small"],
)
Um conjunto de testes que executa um conjunto especificado de testes:
test_suite(
name = "smoke_tests",
tests = [
"system_unittest",
"public_api_unittest",
],
)
Um conjunto de testes para executar todos os testes no pacote atual que não são instáveis.
test_suite(
name = "non_flaky_test",
tags = ["-flaky"],
)
Argumentos
| Atributos | |
|---|---|
name |
Nome: obrigatório Um nome exclusivo para essa segmentação. |
tags
|
Lista de strings não configuráveis; 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 "small" 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. Somente as regras de teste que correspondem a todas as tags positivas e nenhuma das tags negativas serão incluídas no conjunto de testes. Isso não significa que a verificação de erros para dependências de testes filtrados seja ignorada. As dependências de testes ignorados ainda precisam ser válidas (por exemplo, não bloqueadas por restrições de visibilidade).
A palavra-chave da tag
O
Se você precisar de um |
tests
|
Lista de rótulos; não configurável; o padrão é
Qualquer
Se o atributo |