test run

Sinopsis

codeql test run [--threads=<num>] [--ram=<MB>] <options>... -- <test|dir>...

codeql test run [--threads=<num>] [--ram=<MB>] <options>... -- <test|dir>...

Descripción

Ejecuta pruebas unitarias para consultas QL.

Opciones

Opciones principales

<test|dir>...

Cada argumento es uno de los siguientes:

• Un archivo .ql o .qlref que define una prueba que se va a ejecutar.
• Directorio en el que se buscarán de manera recursiva las pruebas que se van a ejecutar.

--failing-exitcode=<code>

[Avanzado] Establece el código de salida para generar si se encuentran errores. Normalmente es 1, pero las herramientas que analizan la salida pueden resultar útiles para establecerlo en 0.

--format=<fmt>

Selecciona el formato de salida. Opciones posibles:

text (predeterminado) : representación textual en lenguaje natural.

json: matriz JSON secuenciada de objetos de resultado de la prueba.

betterjson: matriz JSON secuenciada de objetos de evento.

jsonz: secuencia de objetos JSON de resultado de la prueba terminados en cero.

betterjsonz: secuencia de objetos JSON de evento terminados en cero.

Para los formatos betterjson y betterjsonz, cada evento tiene una propiedad type que especifica el tipo del evento. En el futuro podrían agregarse nuevos tipos de evento, por lo que los consumidores deben omitir cualquier evento con una propiedad kind no reconocida.

--[no-]keep-databases

[Avanzado] Conserva las bases de datos extraídas para ejecutar las consultas de prueba, incluso cuando se superen todas las pruebas de un directorio. (La base de datos siempre estará presente cuando se produzcan errores en algunas pruebas).

--[no-]fast-compilation

[En desuso] [Avanzado] Omite los pasos de optimización especialmente lentos al compilar consultas de prueba.

--[no-]learn

[Avanzado] Cuando una prueba genera una salida inesperada, en lugar de mostrar un error, actualiza su archivo .expected para que coincida con la salida real, de manera que pase la prueba. De todos modos, las pruebas pueden generar errores en este modo; por ejemplo, si no se completa correctamente la creación de una base de datos de prueba para realizar consultas.

--consistency-queries=<dir>

[Avanzado] Un directorio con consultas de coherencia que se ejecutarán para cada base de datos de prueba. Estas consultas no deben generar ninguna salida (excepto cuando encuentren un problema), a menos que el directorio de prueba incluya un subdirectorio CONSISTENCY con un archivo .expected. Esto resulta útil principalmente para probar los extractores.

--[no-]check-databases

[Avanzado] Ejecuta codeql dataset check en cada base de datos de prueba que se haya creado e informa un error si se detectan incoherencias. Esto resulta útil al probar extractores. Si se espera que la comprobación genere un error (temporal) en una base de datos determinada, coloca un archivo DB-CHECK.expected en el directorio de prueba.

--[no-]show-extractor-output

[Avanzado] Muestra la salida de los scripts de extractor que crean bases de datos de prueba. Puede ser útil al desarrollar o editar casos de prueba. Ten en cuenta que puede causar salidas duplicadas o con formato incorrecto si se usa con varios subprocesos.

-M, --ram=<MB>

Establece la cantidad total de RAM que se debe permitir usar al ejecutor de prueba.

--slice=<N/M>

[Avanzado] Divide los casos de prueba en M trozos de tamaño aproximadamente igual y procesa solo el enésimo de ellos. Esto se puede usar para la paralelización manual del proceso de prueba.

--[no-]strict-test-discovery

[Avanzado] Usa solo consultas que se puedan identificar de forma segura como pruebas. Este modo intenta distinguir entre los archivos .ql que definen pruebas unitarias y los archivos .ql destinados a ser consultas útiles. Esta opción la usan herramientas (como los IDE) que necesitan identificar todas las pruebas unitarias de un árbol de directorio sin que esto dependa de saber previamente cómo se organizan los archivos de este.

Dentro de un paquete de QL cuyo objeto qlpack.yml declara un directorio tests, todos los archivos .ql de ese directorio se consideran pruebas y se omitirán los archivos .ql que se encuentren fuera de él. En un paquete de QL que no declare un directorio tests, un archivo .ql se identifica como prueba solo si tiene un archivo .expected correspondiente.

Para mantener la coherencia, los archivos .qlref están limitados por las mismas reglas que los archivos .ql, aunque un archivo .qlref solo puede ser de prueba.

Opciones para buscar las bibliotecas y los extractores que las pruebas usan

--search-path=<dir>[:<dir>...]

Lista de directorios en los que se pueden encontrar paquetes de QL. Cada directorio puede ser un paquete de QL (o una agrupación de paquetes que contenga un archivo .codeqlmanifest.json en la raíz) o el elemento primario inmediato de uno o varios directorios de este tipo.

Si la ruta de acceso contiene más de un directorio, su orden define la prioridad entre ellos: cuando un nombre de paquete que se debe resolver tiene coincidencias en más de uno de los árboles de directorio, tiene prioridad el que se indica primero.

Apuntar esto a una extracción del repositorio CodeQL de código abierto debería funcionar al consultar uno de los lenguajes que residen allí.

Si extrajiste el repositorio CodeQL como un elemento relacionado de la cadena de herramientas CodeQL desempaquetada, no es necesario proporcionar esta opción; dichos directorios del mismo nivel siempre se buscarán paquetes de QL que no se encuentren de otro modo. (Si este valor predeterminado no funciona, se recomienda encarecidamente configurar --search-path de una vez en un archivo de configuración por usuario).

(Nota: En Windows, el separador de ruta de acceso es ;).

--additional-packs=<dir>[:<dir>...]

Si se da esta lista de directorios, se buscarán paquetes en ellos antes que en los incluidos en --search-path. El orden entre ellos no importa; si se encuentra un nombre de paquete en dos lugares diferentes de esta lista es un error.

Esto resulta útil si estás desarrollando temporalmente una versión nueva de un paquete que también aparece en la ruta de acceso predeterminada. Por otro lado, no se recomienda reemplazar esta opción en un archivo de configuración; algunas acciones internas agregarán esta opción sobre la marcha y reemplazarán cualquier valor configurado.

(Nota: En Windows, el separador de ruta de acceso es ;).

--library-path=<dir>[:<dir>...]

[Avanzado] Lista opcional de los directorios que se agregarán a la ruta de búsqueda de importación sin procesar para las bibliotecas de QL. Esto solo debe usarse si usas bibliotecas de QL que no se han empaquetado como paquetes de QL.

(Nota: En Windows, el separador de ruta de acceso es ;).

--dbscheme=<file>

[Avanzado] Define explícitamente las consultas dbscheme en las que se debe realizar la compilación. Esto solo debe proporcionarse a los autores de llamadas que están extremadamente seguros de lo que están haciendo.

--compilation-cache=<dir>

[Avanzado] Especifica un directorio adicional que se va a usar como caché de compilación.

--no-default-compilation-cache

[Avanzado] No uses cachés de compilación en ubicaciones estándar, como en el paquete de QL que contiene la consulta o en el directorio de la cadena de herramientas de CodeQL.

Opciones para configurar el administrador de paquetes de CodeQL

--registries-auth-stdin

Autentícate en los registros de contenedores de servidor de GitHub Enterprise; para ello, pasa una lista separada por comas de pares <registry_url>=<token>.

Por ejemplo, puedes pasar https://containers.GHEHOSTNAME1/v2/=TOKEN1,https://containers.GHEHOSTNAME2/v2/=TOKEN2 para autenticarte en dos instancias del servidor de GitHub Enterprise.

Esto invalida las variables de entorno CODEQL_REGISTRIES_AUTH y GITHUB_TOKEN. Si solo necesitas autenticarte en el registro de contenedor de github.com, puedes hacerlo mediante la opción --github-auth-stdin más sencilla.

--github-auth-stdin

Autentícate en el registro de contenedores de github.com; para ello, pasa un token de aplicaciones de GitHub en github.com o un token de acceso personal mediante la entrada estándar.

Para autenticarte en los registros de contenedores de servidor de GitHub Enterprise, pasa --registries-auth-stdin o usa la variable de entorno CODEQL_REGISTRIES_AUTH.

Esto invalida la variable de entorno GITHUB_TOKEN.

Opciones para controlar la compilación de consultas

--no-release-compatibility

[Avanzado] Usa las características más recientes del compilador, a costa de la portabilidad.

De vez en cuando, el evaluador de QL será compatible con nuevas características del lenguaje QL y optimizaciones del evaluador unas cuantas versiones antes de que se habiliten de forma predeterminada en el compilador de QL. Esto ayuda a garantizar que el rendimiento que experimentes al desarrollar consultas en la versión de CodeQL más reciente puede coincidir con versiones ligeramente anteriores que todavía pueden estar en uso para las integraciones de CI o el examen de código.

Si no te importa que las consultas sean compatibles con otras versiones de CodeQL (anteriores o posteriores), a veces puedes lograr una pequeña cantidad de rendimiento adicional mediante esta marca para habilitar las mejoras recientes en el compilador desde el principio.

En versiones en las que no hay ninguna mejora reciente que se deba habilitar, esta opción silenciosamente no hace nada. Por lo tanto, es seguro establecerla una vez y para todo en el archivo de configuración de CodeQL global.

Disponible desde la versión v2.11.1.

Opciones que controlan la evaluación de consultas de prueba

--[no-]tuple-counting

[Avanzado] Muestra recuentos de tuplas para cada uno de los pasos de evaluación en los registros del evaluador de consultas. Si se proporciona la opción --evaluator-log, los recuentos de tuplas se incluirán en los registros JSON estructurados y basados en texto generados por el comando. (Esto puede ser útil para la optimización del rendimiento del código QL complejo).

--timeout=<seconds>

[Avanzado] Establece la duración del tiempo de espera para la evaluación de consultas, en segundos.

La característica de tiempo de espera está pensada para detectar los casos en los que una consulta compleja tardaría "una eternidad" en evaluarse. No es una forma eficaz de limitar la cantidad total de tiempo que puede tardar la evaluación de la consulta. La evaluación podrá continuar siempre y cuando cada parte cronometrada por separado del cálculo se complete dentro del plazo de tiempo de espera. Actualmente, estas partes cronometradas por separado son "capas de RA" de la consulta optimizada, lo cual puede cambiar en el futuro.

Si no se especifica el tiempo de espera o se define como 0, no se establecerá tiempo de espera (excepto para codeql test run, donde el tiempo de espera predeterminado es de 5 minutos).

-j, --threads=<num>

Usa todos estos subprocesos para evaluar las consultas.

De manera predeterminada, su valor es 1. Puedes pasar 0 para usar un subproceso por núcleo en la máquina o -N para dejar N núcleos sin utilizar (excepto que aún se usa al menos un subproceso).

Opciones para controlar la salida de registros de evaluador estructurados

--evaluator-log=<file>

[Avanzado] Genera registros estructurados sobre el rendimiento del evaluador en el archivo especificado. El formato de este archivo de registro está sujeto a cambios sin previo aviso, pero será una secuencia de objetos JSON separados por dos caracteres de nueva línea (opción predeterminada) o por uno si se pasa la opción --evaluator-log-minify. Usa codeql generate log-summary <file> para generar un resumen más estable de este archivo y evita analizar el archivo directamente. Si el archivo ya existe, se sobrescribirá.

--evaluator-log-minify

[Avanzado] Si se pasa la opción --evaluator-log, al pasar también esta opción se minimizará el tamaño del registro JSON generado, a costa de un resultado mucho menos legible.

Opciones para comprobar TRAP importado

--[no-]check-undefined-labels

[Avanzado] Notifica errores de etiquetas no definidas.

--[no-]check-unused-labels

[Avanzado] Notifica errores de etiquetas sin usar.

--[no-]check-repeated-labels

[Avanzado] Notifica errores de etiquetas repetidas.

--[no-]check-redefined-labels

[Avanzado] Notifica errores de etiquetas redefinidas.

--[no-]check-use-before-definition

[Avanzado] Notifica errores de etiquetas usadas antes de definirlas.

--[no-]fail-on-trap-errors

[Avanzado] Sale con un valor distinto de cero si se produce un error durante la importación de capturas.

--[no-]include-location-in-star

[Avanzado] Construye identificadores de entidad que codifican la ubicación en el archivo TRAP del que proceden. Puede ser útil para la depuración de generadores TRAP, pero ocupa mucho espacio en el conjunto de datos.

--[no-]linkage-aware-import

[Avanzado] Controla si codeql dataset import reconoce la vinculación (valor predeterminado) o no. En los proyectos en los que esta parte de la creación de la base de datos consume demasiada memoria, deshabilitar esta opción puede ayudarles a avanzar a costa de la integridad de la base de datos.

Disponible desde la versión v2.15.3.

Opciones comunes

-h, --help

Muestra este texto de ayuda.

-J=<opt>

[Avanzado] Asigna la opción a la JVM que ejecuta el comando.

(Ten en cuenta que las opciones que contienen espacios no se administrarán correctamente).

-v, --verbose

Aumenta incrementalmente el número de mensajes de progreso impresos.

-q, --quiet

Reduce incrementalmente el número de mensajes de progreso impresos.

--verbosity=<level>

[Avanzado] Establece explícitamente el nivel de detalle en errores, advertencias, progreso, progreso+, progreso++, progreso+++. Invalida -v y -q.

--logdir=<dir>

[Avanzado] Escribe registros detallados en uno o varios archivos del directorio especificado, con nombres generados que incluyen marcas de tiempo y el nombre del subcomando en ejecución.

(Para escribir un archivo de registro con un nombre sobre el que tienes control total, proporciona --log-to-stderr y redirige stderr como quieras).

--common-caches=<dir>

[Avanzado] Controla la ubicación de los datos en caché del disco que se conservarán entre varias ejecuciones de la CLI, como paquetes QL descargados y planes de consulta compilada. Si no se define explícitamente, se toma como predeterminado un directorio denominado .codeql en el directorio principal del usuario, que se creará en caso de que no exista.

Disponible desde la versión v2.15.2.