Reglas
Alias
Ver el código fuente de la reglaalias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
La regla alias
crea otro nombre con el que se puede hacer referencia a una regla.
La asignación de alias solo funciona para objetivos “comunes”. En particular, package_group
y test_suite
no pueden tener un alias.
La asignación de alias puede ser útil en repositorios grandes en los que cambiar el nombre de un destino requeriría realizar cambios en muchos archivos. También puedes usar una regla de alias para almacenar una llamada a la función select si deseas reutilizar esa lógica para varios destinos.
La regla de alias tiene su propia declaración de visibilidad. En todos los demás aspectos, se comporta como la regla a la que hace referencia (p.ej., solo se ignora en el alias de prueba; en su lugar se usa el carácter de solo prueba de la regla a la que se hace referencia) con algunas excepciones menores:
-
Las pruebas no se ejecutan si su alias se menciona en la línea de comandos. Para definir un alias que ejecute la prueba a la que se hace referencia, usa una regla
test_suite
con un solo objetivo en su atributotests
. -
Cuando se definen grupos de entornos, no se admiten los alias de las reglas
environment
. Tampoco se admiten en la opción de línea de comandos--target_environment
.
Ejemplos
filegroup( name = "data", srcs = ["data.txt"], ) alias( name = "other", actual = ":data", )
Argumentos
Atributos | |
---|---|
name |
Name; obligatorio Un nombre único para este destino. |
actual
|
Label; obligatorio El objetivo al que hace referencia este alias. No es necesario que sea una regla; también puede ser un archivo de entrada. |
config_setting
Ver el código fuente de la reglaconfig_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
Coincide con un estado de configuración esperado (expresado como marcas de compilación o restricciones de plataforma) para activar atributos configurables. Consulta la selección para saber cómo consumir esta regla y la sección Atributos configurables para obtener una descripción general de la función general.
Ejemplos
La siguiente coincide con cualquier compilación que configure --compilation_mode=opt
o -c opt
(ya sea de manera explícita en la línea de comandos o implícitamente desde archivos .bazelrc):
config_setting( name = "simple", values = {"compilation_mode": "opt"} )
La siguiente coincide con cualquier compilación que se oriente a ARM y aplique el FOO=bar
de definición personalizada (por ejemplo, bazel build --cpu=arm --define FOO=bar ...
):
config_setting( name = "two_conditions", values = { "cpu": "arm", "define": "FOO=bar" } )
La siguiente compilación coincide con cualquier compilación que establezca la marca definida por el usuario
--//custom_flags:foo=1
(ya sea de forma explícita en la línea de comandos o implícitamente desde archivos .bazelrc):
config_setting( name = "my_custom_flag_is_set", flag_values = { "//custom_flags:foo": "1" }, )
La siguiente compilación coincide con cualquier compilación orientada a una plataforma con arquitectura x86_64 y versión 2.25 de glibc, suponiendo la existencia de un constraint_value
con la etiqueta //example:glibc_2_25
. Ten en cuenta que una plataforma coincide si define valores de restricción adicionales superiores a estos dos.
config_setting( name = "64bit_glibc_2_25", constraint_values = [ "@platforms//cpu:x86_64", "//example:glibc_2_25", ] )En todos estos casos, es posible que la configuración cambie dentro de la compilación, por ejemplo, si se debe compilar un destino para una plataforma diferente a la de su dependencia. Esto significa que, incluso cuando un
config_setting
no coincida con las marcas de la línea de comandos de nivel superior, podría coincidir con algunos objetivos de compilación.
Notas
- Consulta la selección para saber qué sucede cuando varios
config_setting
coinciden con el estado de configuración actual. - Para las marcas que admiten formas abreviadas (p. ej.,
--compilation_mode
frente a-c
), las definiciones devalues
deben usar la forma completa. Coinciden automáticamente con las invocaciones con cualquier forma. -
Si una marca toma varios valores (como
--copt=-Da --copt=-Db
o una marca de Starlark de tipo lista),values = { "flag": "a" }
coincide si"a"
está presente en cualquier lugar de la lista real.values = { "myflag": "a,b" }
funciona de la misma manera: coincide con--myflag=a --myflag=b
,--myflag=a --myflag=b --myflag=c
,--myflag=a,b
y--myflag=c,b,a
. La semántica exacta varía entre las marcas. Por ejemplo,--copt
no admite varios valores en la misma instancia:--copt=a,b
produce["a,b"]
, mientras que--copt=a --copt=b
produce["a", "b"]
(de modo quevalues = { "copt": "a,b" }
coincide con el primero, pero no con el último). Sin embargo,--ios_multi_cpus
(para las reglas de Apple) sí:-ios_multi_cpus=a,b
yios_multi_cpus=a --ios_multi_cpus=b
producen["a", "b"]
. Verifica las definiciones de las marcas y prueba tus condiciones con cuidado para verificar las expectativas exactas. - Si necesitas definir condiciones que no estén modeladas con marcas de compilación integradas, usa las
marcas definidas por Starlark. También puedes usar
--define
, pero esta opción ofrece una compatibilidad más débil y no se recomienda. Consulta este vínculo para obtener más información. - Evita repetir definiciones idénticas de
config_setting
en diferentes paquetes. En su lugar, haz referencia a unconfig_setting
común que se definió en un paquete canónico. values
,define_values
yconstraint_values
se pueden usar con cualquier combinación en el mismoconfig_setting
, pero se debe establecer al menos uno para unconfig_setting
dado.
Argumentos
Atributos | |
---|---|
name |
Name; obligatorio Un nombre único para este destino. |
constraint_values
|
Lista de etiquetas; no configurable; el valor predeterminado es constraint_values que debe especificar la plataforma de destino para que coincida con este config_setting . (La plataforma de ejecución no se considera aquí). Se ignorará cualquier valor de restricción adicional que tenga la plataforma. Consulta
Atributos de compilación configurables para obtener más detalles.
Cuando dos |
define_values
|
Diccionario: String -> String; no configurable; el valor predeterminado es values , pero específicamente para la marca --define .
Esto significa lo siguiente: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) no funciona porque la misma clave ( config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) coincide correctamente con
|
flag_values
|
Diccionario: etiqueta -> String; no configurable; el valor predeterminado es values , pero para
marcas de compilación definidas por el usuario.
Este es un atributo distinto porque se hace referencia a las marcas definidas por el usuario como etiquetas, mientras que a las marcas integradas se hace referencia a ellas como cadenas arbitrarias. |
values
|
Diccionario: String -> String; no configurable; el valor predeterminado es Esta regla hereda la configuración del destino configurado que hace referencia a él en una declaración Para mayor comodidad, los valores de configuración se especifican como marcas de compilación (sin el Si una marca no se establece de forma explícita en la línea de comandos, se usa su valor predeterminado.
Si una clave aparece varias veces en el diccionario, solo se usa la última instancia.
Si una clave hace referencia a una marca que se puede establecer varias veces en la línea de comandos (p.ej.,
|
grupo de archivos
Ver el código fuente de la reglafilegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
Usa filegroup
para asignar un nombre conveniente a una colección de destinos.
Luego, otras reglas pueden hacer referencia a ellas.
Se recomienda usar filegroup
en lugar de hacer referencia a directorios directamente.
Este último no tiene sonido, ya que el sistema de compilación no tiene conocimiento completo de todos los archivos que se encuentran debajo del directorio, por lo que es posible que no se vuelva a compilar cuando cambien estos archivos. Cuando se combina con glob, filegroup
puede garantizar que todos los archivos sean conocidos de manera explícita por el sistema de compilación.
Ejemplos
Para crear un filegroup
que conste de dos archivos de origen, haz lo siguiente:
filegroup( name = "mygroup", srcs = [ "a_file.txt", "some/subdirectory/another_file.txt", ], )
O bien, usa un glob
para agrupar un directorio testdata:
filegroup( name = "exported_testdata", srcs = glob([ "testdata/*.dat", "testdata/logs/**/*.log", ]), )
Para usar estas definiciones, haz referencia a filegroup
con una etiqueta de cualquier regla:
cc_library( name = "my_library", srcs = ["foo.cc"], data = [ "//my_package:exported_testdata", "//my_package:mygroup", ], )
Argumentos
Atributos | |
---|---|
name |
Name; obligatorio Un nombre único para este destino. |
srcs
|
Lista de etiquetas; el valor predeterminado es
Es común usar el resultado de una expresión glob para el valor del atributo |
data
|
Lista de etiquetas; el valor predeterminado es
Los destinos nombrados en el atributo |
output_group
|
String; el valor predeterminado es Un “grupo de salida” es una categoría de artefactos de salida de un objetivo, que se especifica en la implementación de esa regla. |
consulta generativa
Ver el código fuente de la reglagenquery(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()
ejecuta una consulta especificada en el lenguaje de consulta Blaze y vuelca el resultado en un archivo.
Para mantener la coherencia de la compilación, la consulta solo puede visitar el cierre transitivo de los destinos especificados en el atributo scope
. Las consultas que infrinjan esta regla fallarán durante la ejecución si strict
no se especifica o es verdadero (si strict
es falso, los destinos fuera del permiso simplemente se omitirán con una advertencia). La forma más fácil de asegurarte de que esto no suceda es mencionar las mismas etiquetas en el alcance que en la expresión de la consulta.
La única diferencia entre las consultas permitidas aquí y en la línea de comandos es que las consultas que contienen especificaciones de destino comodín (p.ej., //pkg:*
o //pkg:all
) no se permiten aquí.
Esto se debe a dos motivos: en primer lugar, porque genquery
debe especificar un permiso para evitar que los destinos fuera del cierre transitivo de la consulta influyan en su resultado y, en segundo lugar, porque los archivos BUILD
no admiten dependencias de comodines (p.ej., no se permite deps=["//a/..."]
).
El resultado de la consulta de generación de demanda está ordenado de manera lexicográfica para aplicar un resultado determinista,
a excepción de --output=graph|minrank|maxrank
o cuando somepath
se usa como la función de nivel superior.
El nombre del archivo de salida es el nombre de la regla.
Ejemplos
En este ejemplo, se escribe la lista de etiquetas del cierre transitivo del destino especificado en un archivo.
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
Argumentos
Atributos | |
---|---|
name |
Name; obligatorio Un nombre único para este destino. |
compressed_output
|
Booleano; el valor predeterminado es True , el resultado de la consulta se escribe en formato de archivo GZIP. Este parámetro de configuración se puede usar
para evitar aumentos repentinos en el uso de memoria de Bazel cuando se espera que el resultado de la consulta sea grande. Bazel
ya comprime de forma interna los resultados de las consultas de más de 220 bytes, sin importar
el valor de esta configuración, por lo que establecerla en True es posible que no reduzca el montón
retenido. Sin embargo, permite que Bazel omita la descompresión cuando escribe el archivo de salida,
lo que puede consumir mucha memoria.
|
expression
|
String; obligatoria La consulta que se ejecutará. A diferencia de la línea de comandos y otros lugares en los archivos BUILD, aquí las etiquetas se resuelven en relación con el directorio raíz del lugar de trabajo. Por ejemplo, la etiqueta:b en este atributo en el archivo a/BUILD hará referencia al //:b de destino.
|
opts
|
Lista de cadenas; el valor predeterminado es bazel query . Algunas opciones de consulta no están permitidas aquí: --keep_going , --query_file , --universe_scope , --order_results y --order_output . Las opciones que no se especifiquen aquí tendrán sus valores predeterminados al igual que en la línea de comandos de bazel query .
|
scope
|
Lista de etiquetas; obligatorio El alcance de la consulta. La consulta no puede llegar a objetivos táctiles fuera del cierre transitivo de estos objetivos. |
strict
|
Booleano; el valor predeterminado es |
genrule
Ver el código fuente de la reglagenrule(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)
Una genrule
genera uno o más archivos con un comando Bash definido por el usuario.
Las genrules son reglas de compilación genéricas que puedes usar si no hay una regla específica para la tarea.
Por ejemplo, puedes ejecutar un mensaje de una sola línea en Bash. Sin embargo, si necesitas compilar archivos C++, cumple con las reglas cc_*
existentes, porque todo el trabajo pesado ya está hecho por ti.
Ten en cuenta que genrule requiere una shell para interpretar el argumento del comando. También es fácil hacer referencia a programas arbitrarios disponibles en la RUTA DE ACCESO. Sin embargo, esto hace que el comando no sea hermético y pueda no ser reproducible. Si solo necesitas ejecutar una herramienta, considera usar run_binary en su lugar.
No uses una genrule para ejecutar pruebas. Existen dispensaciones especiales para pruebas y resultados de
pruebas, incluidas políticas de almacenamiento en caché y variables de entorno. Por lo general, las pruebas deben ejecutarse
después de que se completa la compilación y en la arquitectura de destino, mientras que las genrules se ejecutan durante
la compilación y en la arquitectura de ejecución (las dos pueden ser diferentes). Si necesitas una regla de prueba de uso general, usa sh_test
.
Consideraciones sobre la compilación cruzada
Consulta el manual del usuario para obtener más información sobre la compilación cruzada.
Si bien las genrules se ejecutan durante una compilación, sus resultados suelen usarse después de la compilación, ya sea para implementación o pruebas. Considera el ejemplo de compilación de código C para un microcontrolador: el compilador acepta archivos fuente C y genera código que se ejecuta en un microcontrolador. Obviamente, el código generado no puede ejecutarse en la CPU que se usó para compilarlo, pero el compilador C (si se compiló desde el código fuente) tiene que hacerlo.
El sistema de compilación usa la configuración de ejecución para describir las máquinas en las que se ejecuta la compilación y la configuración de destino para describir las máquinas en las que se debe ejecutar el resultado de la compilación. Proporciona opciones para configurar cada uno de ellos y segrega los archivos correspondientes en directorios separados para evitar conflictos.
En el caso de las genrules, el sistema de compilación garantiza que las dependencias se compilen de forma correcta: srcs
se compilan (si es necesario) para la configuración target, tools
para la configuración exec y se considera que el resultado corresponde a la configuración target. También proporciona
variables "Make" que los comandos de genrule pueden pasar a las herramientas correspondientes.
Es intencional que genrule no defina ningún atributo deps
; otras reglas integradas usan
metainformación que depende del lenguaje que se pasa entre las reglas para determinar automáticamente cómo
controlar las dependientes. Sin embargo, este nivel de automatización no es posible para las genrules. Las genrules funcionan solo a nivel de archivo y runfiles.
Casos especiales
Compilación Exec-exec: En algunos casos, el sistema de compilación debe ejecutar genrules para que el resultado también se pueda ejecutar durante la compilación. Por ejemplo, si una genrule compila algún compilador personalizado
que luego usa otra genrule, el primero debe producir la salida para la
configuración exec, ya que allí es donde se ejecutará el compilador en la otra genrule. En este caso,
el sistema de compilación hace lo correcto automáticamente: compila el srcs
y
el outs
de la primera genrule para la configuración de ejecución en lugar de la configuración de destino. Consulta el manual del usuario para obtener más información.
Herramientas de JDK y C++: Para usar una herramienta del JDK o el paquete del compilador C++, el sistema de compilación proporciona un conjunto de variables para usar. Consulta Variable"Make" para obtener más detalles.
Entorno de Genrule
Una shell Bash configurada para fallar cuando un comando o una canalización falla mediante set -e -o pipefail
ejecuta el comando genrule.
La herramienta de compilación ejecuta el comando Bash en un entorno de procesos depurado que solo define variables principales, como PATH
, PWD
, TMPDIR
y algunas otras.
Para garantizar que las compilaciones sean reproducibles, la mayoría de las variables definidas en el entorno de shell del
usuario no se pasan al comando de genrule. Sin embargo, Bazel (pero no Blaze) pasa por el valor de la variable de entorno PATH
del usuario.
Cualquier cambio en el valor de PATH
hará que Bazel vuelva a ejecutar el comando en la próxima compilación.
Un comando genrule no debe acceder a la red, excepto para conectar procesos secundarios del comando, aunque esto no se aplica de manera forzosa en la actualidad.
El sistema de compilación borra automáticamente cualquier archivo de salida existente, pero crea los directorios superiores necesarios antes de ejecutar una genrule. También quita todos los archivos de salida en caso de falla.
Consejos generales
- Asegúrate de que las herramientas ejecutadas por una genrule sean deterministas y herméticas. No deben escribir marcas de tiempo en el resultado, y deben usar un orden estable para conjuntos y mapas, además de escribir solo rutas de acceso de archivo relativas al resultado, no absolutas. Si no se sigue esta regla, se generará un comportamiento de compilación inesperado (Bazel no volverá a compilar una genrule que esperabas) y se degradará el rendimiento de la caché.
- Usa
$(location)
ampliamente para resultados, herramientas y fuentes. Debido a la segregación de los archivos de salida para diferentes parámetros de configuración, las genrules no pueden depender de rutas hard-coded o absolutas. - Escribe una macro de Starlark común en caso de que se usen genrules iguales o muy similares en varios lugares. Si la genrule es compleja, considera implementarla en una secuencia de comandos o como una regla de Starlark. Esto mejora la legibilidad y la capacidad de prueba.
- Asegúrate de que el código de salida indique correctamente el éxito o el fracaso de la genrule.
- No escribas mensajes informativos en stdout ni stderr. Si bien es útil para la depuración, esto puede convertirse fácilmente en ruido. Una genrule exitosa debe ser silenciosa. Por otro lado, una genrule con fallas debería emitir mensajes de error correctos.
$$
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)
.- Evita crear symlinks y directorios. Bazel no realiza copias de la estructura de directorios o symlinks creados por genrules y su verificación de dependencias de los directorios no es correcta.
- Cuando haces referencia a la genrule en otras reglas, puedes usar la etiqueta de la genrule o las
etiquetas de archivos de salida individuales. A veces, un enfoque es más legible y, a veces, el otro: hacer referencia a los resultados por nombre en el
srcs
de una regla de consumo evitará tomar involuntariamente otros resultados de la regla general, pero puede ser tedioso si esta produce muchos resultados.
Ejemplos
En este ejemplo, se genera foo.h
. No hay fuentes, porque el comando no acepta ninguna entrada. El “binario” que ejecuta el comando es una secuencia de comandos de Perl en el mismo paquete que la genrule.
genrule( name = "foo", srcs = [], outs = ["foo.h"], cmd = "./$(location create_foo.pl) > \"$@\"", tools = ["create_foo.pl"], )
En el siguiente ejemplo, se muestra cómo usar un filegroup
y las salidas de otro genrule
. Ten en cuenta que también funcionaría el uso de $(SRCS)
en lugar de directivas $(location)
explícitas. En este ejemplo, se usa esta última para una demostración.
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 |
Name; obligatorio Un nombre único para este destino. Puedes hacer referencia a esta regla por su nombre en la sección srcs o deps de otras reglas BUILD . Si la regla genera archivos de origen, debes usar el atributo srcs .
|
srcs
|
Lista de etiquetas; el valor predeterminado es
Estos atributos no son adecuados para enumerar las herramientas que ejecuta
El sistema de compilación garantiza que estos requisitos se compilen antes de ejecutar el comando
genrule; se compilan con la misma configuración que la solicitud de compilación original. Los nombres de los archivos de estos requisitos previos están disponibles para el comando como una lista separada por espacios en |
outs
|
Lista de nombres de archivo; no configurable; obligatorio Una lista de los archivos que genera esta regla.Los archivos de salida no deben cruzar los límites del paquete. Los nombres de los archivos de salida se interpretan como relativos al paquete.
Si se configura la marca
Se espera que el comando genrule cree cada archivo de salida en una ubicación predeterminada.
La ubicación está disponible en |
cmd
|
String; el valor predeterminado es $(location)
y la variable "Make".
cmd_bash , cmd_ps y cmd_bat ,
si ninguno de ellos es aplicable.
Si la longitud de la línea de comandos supera el límite de la plataforma (64,000 en Linux/macOS y 8,000 en Windows), genrule escribirá el comando en una secuencia de comandos y la ejecutará para solucionar el problema. Esto se aplica a todos los atributos cmd ( |
cmd_bash
|
String; el valor predeterminado es Este atributo tiene mayor prioridad que |
cmd_bat
|
String; el valor predeterminado es Este atributo tiene mayor prioridad que
|
cmd_ps
|
String; el valor predeterminado es Este atributo tiene mayor prioridad que
Para que PowerShell sea más fácil de usar y menos propenso a errores, ejecutamos los siguientes comandos para configurar el entorno antes de ejecutar el comando de PowerShell en genrule.
|
executable
|
Booleano; no configurable; el valor predeterminado es
Si estableces esta marca como verdadera, el resultado es un archivo ejecutable y se puede ejecutar con el comando No se admite la declaración de dependencias de datos para el ejecutable generado. |
local
|
Booleano; el valor predeterminado es
Si se establece en True, esta opción obliga a este
Esto equivale a proporcionar una etiqueta "local" ( |
message
|
String; el valor predeterminado es
Un mensaje de progreso que se imprimirá a medida que se ejecute este paso de compilación. Según la configuración predeterminada, el mensaje dice "Generando resultado" (o un texto igualmente insulso), pero puedes proporcionar uno más específico. Usa este atributo en lugar de |
output_licenses
|
Tipo de licencia; el valor predeterminado es common attributes
.
|
output_to_bindir
|
Booleano; no configurable; el valor predeterminado es
Si se establece como verdadera, esta opción hace que los archivos de salida se escriban en el directorio |
tools
|
Lista de etiquetas; el valor predeterminado es
El sistema de compilación garantiza que estos requisitos se compilen antes de ejecutar el comando genrule;
que se compilan con la configuración exec, ya que estas herramientas se ejecutan como parte de la compilación. La ruta de un
Cualquier |
starlark_doc_extract
Ver el código fuente de la reglastarlark_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()
extrae la documentación de las reglas, las funciones (incluidas las macros), los aspectos y los proveedores definidos o reexportados en un archivo .bzl
o .scl
determinado. El resultado de esta regla es un proto binario ModuleInfo
, como se define
en
stardoc_output.proto
en el árbol de fuentes de Bazel.
Destinos de salida implícitos
name.binaryproto
(el resultado predeterminado): Es un proto binarioModuleInfo
.name.textproto
(solo se compila si se solicita de manera explícita): Es la versión proto de texto dename.binaryproto
.
Advertencia: No se garantiza que el formato de salida de esta regla sea estable. Está destinado principalmente para uso interno de Stardoc.
Argumentos
Atributos | |
---|---|
name |
Name; obligatorio Un nombre único para este destino. |
deps
|
Lista de etiquetas; el valor predeterminado es load() mediante src . En el uso normal, estos objetivos deben ser objetivos bzl_library , pero la regla starlark_doc_extract no lo aplica y acepta cualquier destino que proporcione archivos de Starlark en su DefaultInfo .
Ten en cuenta que los archivos de Starlark unidos deben estar en el árbol de fuentes. Bazel no puede
|
src
|
Label; obligatorio Un archivo de Starlark del que se extrae la documentación.Ten en cuenta que debe ser un archivo del árbol de fuentes. Bazel no puede |
render_main_repo_name
|
Booleano; el valor predeterminado es //foo:bar.bzl se emitirá como @main_repo_name//foo:bar.bzl ).
El nombre que se usará para el repositorio principal se obtiene de Este atributo debe establecerse en |
symbol_names
|
Lista de cadenas; el valor predeterminado es
|
test_suite
Ver el código fuente de la reglatest_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
Un test_suite
define un conjunto de pruebas que se consideran "útiles" para los humanos. Esto permite que los proyectos definan conjuntos de pruebas, como "pruebas que debes ejecutar antes del registro", "pruebas de esfuerzo de nuestro proyecto" o "todas las pruebas pequeñas". El comando blaze test
respeta este tipo de organización: en una invocación como blaze test //some/test:suite
, Blaze primero enumera todos los destinos de prueba incluidos de forma transitiva en el destino //some/test:suite
(que llamamos "expansión del paquete de prueba"), luego, Blaze compila y prueba esos destinos.
Ejemplos
Un conjunto de pruebas para ejecutar todas las pruebas de nivel inferior en el paquete actual.
test_suite( name = "small_tests", tags = ["small"], )
Un paquete de pruebas que ejecuta un conjunto específico de pruebas:
test_suite( name = "smoke_tests", tests = [ "system_unittest", "public_api_unittest", ], )
Un conjunto de pruebas para ejecutar todas las pruebas que no sean inestables en el paquete actual.
test_suite( name = "non_flaky_test", tags = ["-flaky"], )
Argumentos
Atributos | |
---|---|
name |
Name; obligatorio Un nombre único para este destino. |
tags
|
Lista de cadenas; no configurable; el valor predeterminado es Las etiquetas que comienzan con un carácter "-" se consideran etiquetas negativas. El carácter "-" anterior no se considera parte de la etiqueta, por lo que una etiqueta de conjunto de "-small" coincide con el tamaño "pequeño" de una prueba. Todas las demás etiquetas se consideran positivas. De manera opcional, para que las etiquetas positivas sean más explícitas, las etiquetas también pueden comenzar con el carácter "+", que no se evaluará como parte del texto de la etiqueta. Solo hace que la distinción entre positiva y negativa sea más fácil de leer. En el paquete de pruebas, solo se incluirán las reglas de prueba que coincidan con todas las etiquetas positivas y ninguna de las etiquetas negativas. Ten en cuenta que esto no significa que se omite la comprobación de errores en las pruebas que se filtran; las dependencias en las pruebas omitidas aún deben ser legales (p.ej., que no estén bloqueadas por restricciones de visibilidad).
La palabra clave de la etiqueta
Ten en cuenta que el
Si necesitas un |
tests
|
Lista de etiquetas; no configurable; el valor predeterminado es
Aquí se acepta cualquier
Si no se especifica el atributo |