test run

Sinopse

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

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

Descrição

Execute testes de unidade para consultas QL.

Opções

Opções principais

<test|dir>...

Cada argumento é um dos seguintes:

• Um arquivo .ql ou .qlref que define um teste a ser executado.
• Um diretório que será pesquisado recursivamente em busca dos testes a serem executados.

--failing-exitcode=<code>

[Avançado] Defina o código de saída a ser produzido em caso de falhas. Normalmente 1, mas as ferramentas que analisam a saída podem achar útil defini-la como 0.

--format=<fmt>

Selecione o formato de saída. Possíveis opções:

text (padrão) : uma renderização textual legível por humanos.

json: uma matriz JSON transmitida de objetos de resultado do teste.

betterjson: uma matriz JSON transmitida de objetos de evento.

jsonz: um fluxo de objetos de resultado do teste JSON terminado em zero.

betterjsonz: um fluxo de objetos de evento JSON terminado em zero.

Para os formatos betterjson e betterjsonz, cada evento tem uma propriedade type que especifica o tipo do evento. Novos tipos de evento podem ser adicionados no futuro, portanto, os consumidores devem ignorar qualquer evento com uma propriedade kind não reconhecida.

--[no-]keep-databases

[Avançado] Preserve os bancos de dados extraídos para executar as consultas de teste, mesmo quando todos os testes de um diretório são aprovados. (O banco de dados sempre será deixado presente quando houver testes não aprovados).

--[no-]fast-compilation

[Preterido] [Avançado] Omita as etapas de otimização particularmente lentas ao compilar consultas de teste.

--[no-]learn

[Avançado] Quando um teste produzir uma saída inesperada, em vez de produzir uma falha, atualize o arquivo .expected para que ele corresponda à saída real, de modo que ele seja aprovado. Ainda poderá ocorrer uma falha nos testes nesse modo, por exemplo, se a criação de um banco de dados de teste para consulta não for bem-sucedida.

--consistency-queries=<dir>

[Avançado] Um diretório com consultas de consistência que serão executadas para cada banco de dados de teste. Essas consultas não devem produzir nenhuma saída (exceto quando encontrarem um problema), a menos que o diretório de teste inclua um subdiretório CONSISTENCY com um arquivo .expected. Isso é útil principalmente para testar os extratores.

--[no-]check-databases

[Avançado] Execute codeql dataset check em cada banco de dados de teste criado e relate uma falha se ele detectar inconsistências. Isso é útil ao testar os extratores. Se for esperada uma falha (temporária) na verificação em um banco de dados específico, coloque um arquivo DB-CHECK.expected no diretório de teste.

--[no-]show-extractor-output

[Avançado] Mostre a saída de scripts de extratores que criam bancos de dados de teste. Isso pode ser útil ao desenvolver ou editar casos de teste. Use-a com cautela, pois ela pode causar uma saída duplicada ou malformada caso seja usada com vários threads.

-M, --ram=<MB>

Defina a quantidade total de RAM que o executor de teste deve ter permissão para usar.

--slice=<N/M>

[Avançado] Divida os casos de teste em M fatias de tamanho aproximadamente igual e processe apenas a parte N delas. Isso pode ser usado para a paralelização manual do processo de teste.

--[no-]strict-test-discovery

[Avançado] Use apenas consultas que possam ser fortemente identificadas como testes. Esse modo tenta distinguir os arquivos .ql que definem os testes de unidade e os arquivos .ql que devem ser consultas úteis. Essa opção é usada pelas ferramentas, como IDEs, que precisam identificar todos os testes de unidade em uma árvore de diretório sem depender do conhecimento anterior de como os arquivos nela são organizados.

Em um pacote QL cujo qlpack.yml declara um diretório tests, todos os arquivos .ql nesse diretório são considerados testes e os arquivos .ql fora dele são ignorados. Em um pacote QL que não declara um diretório tests, um arquivo .ql é identificado como um teste somente se ele tem um arquivo .expected correspondente.

Para fins de consistência, os arquivos .qlref são limitados pelas mesmas regras que os arquivos .ql, mesmo que um arquivo .qlref não possa realmente ser do tipo não teste.

Opções para encontrar as bibliotecas e os extratores usados pelos testes

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

Uma lista de diretórios nos quais os pacotes QL podem ser encontrados. Cada diretório pode ser um pacote QL (ou um conjunto de pacotes que contém um arquivo .codeqlmanifest.json na raiz) ou o pai imediato de um ou mais desses diretórios.

Se o caminho contiver mais de um diretório, a ordem deles definirá a precedência entre eles: quando for encontrada uma correspondência do nome de um pacote que precisa ser resolvido em mais de uma das árvores do diretório, a primeira fornecida vencerá.

Se você apontar isso para um check-out do repositório do CodeQL de código aberto, isso deverá funcionar durante a consulta de uma das linguagens que se encontram nele.

Se você tiver feito check-out do repositório do CodeQL como um irmão da cadeia de ferramentas CodeQL descompactada, não precisará fornecer essa opção. Nesses diretórios irmãos, sempre será feita a pesquisa por pacotes QL que não podem ser encontrados de outra forma. (Caso esse padrão não funcione, recomendamos fortemente configurar --search-path de uma vez por todas em um arquivo de configuração por usuário).

(Observação: no Windows, o separador de caminho é ;).

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

Se essa lista de diretórios for fornecida, nesses diretórios, será feita a pesquisa de pacotes antes daqueles contidos em --search-path. A ordem entre eles não importa: será indicado um erro se o nome de um pacote for encontrado em dois locais diferentes nessa lista.

Isso será útil se você estiver desenvolvendo temporariamente uma nova versão de um pacote que também aparece no caminho padrão. Por outro lado, não recomendamos substituir essa opção em um arquivo de configuração. Algumas ações internas adicionarão essa opção em tempo real, substituindo qualquer valor configurado.

(Observação: no Windows, o separador de caminho é ;).

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

[Avançado] Uma lista opcional de diretórios que serão adicionados ao caminho de pesquisa de importação bruta para as bibliotecas QL. Isso só deverá ser usado se você estiver usando bibliotecas QL que não foram empacotadas como pacotes QL.

(Observação: no Windows, o separador de caminho é ;).

--dbscheme=<file>

[Avançado] Defina explicitamente o dbscheme no qual as consultas devem ser compiladas. Isso só deve ser fornecido pelos chamadores que têm certeza do que estão fazendo.

--compilation-cache=<dir>

[Avançado] Especifique um diretório adicional a ser usado como um cache de compilação.

--no-default-compilation-cache

[Avançado] Não use caches de compilação em locais padrão, como no pacote QL que contém a consulta ou no diretório de cadeia de ferramentas CodeQL.

Opções para configurar o gerenciador de pacotes CodeQL

--registries-auth-stdin

Autentique-se nos registros de contêiner do GitHub Enterprise Server transmitindo uma lista separada por vírgula de pares <registry_url>=<token>.

Por exemplo, você pode transmitir https://containers.GHEHOSTNAME1/v2/=TOKEN1,https://containers.GHEHOSTNAME2/v2/=TOKEN2 para se autenticar em duas instâncias do GitHub Enterprise Server.

Isso substitui as variáveis de ambiente CODEQL_REGISTRIES_AUTH e GITHUB_TOKEN. Se você só precisar se autenticar no registro de contêiner do github.com, poderá se autenticar usando a opção --github-auth-stdin mais simples.

--github-auth-stdin

Autentique-se no registro de contêiner do github.com transmitindo um token do GitHub Apps do github.com ou um token de acesso pessoal por meio da entrada padrão.

Para se autenticar nos registros de contêiner do GitHub Enterprise Server, transmita --registries-auth-stdin ou use a variável de ambiente CODEQL_REGISTRIES_AUTH.

Isso substitui a variável de ambiente GITHUB_TOKEN.

Opções para controlar a compilação de consultas

--no-release-compatibility

[Avançado] Use os recursos mais recentes do compilador, em detrimento da portabilidade.

De tempos em tempos, novos recursos da linguagem QL e otimizações do avaliador terão suporte do avaliador de QL algumas versões antes de serem habilitadas por padrão no compilador de QL. Isso ajuda a garantir que o desempenho que você experimenta ao desenvolver consultas na versão mais recente do CodeQL possa ser equivalente ao de versões um pouco mais antigas que ainda podem estar em uso para a verificação de código ou as integrações de CI.

Se você não se importa que suas consultas sejam compatíveis com outras versões (anteriores ou posteriores) do CodeQL, às vezes, você pode obter uma pequena quantidade de desempenho extra usando esse sinalizador para habilitar aprimoramentos recentes no compilador antecipadamente.

Nas versões em que não há aprimoramentos recentes a serem habilitados, essa opção silenciosamente não executa nenhuma ação. Portanto, é seguro defini-la de uma vez por todas no arquivo de configuração global do CodeQL.

Disponível desde v2.11.1.

Opções que controlam a avaliação das consultas de teste

--[no-]tuple-counting

[Avançado] Veja as contagens de tupla de cada etapa de avaliação nos logs do avaliador de consulta. Se a opção --evaluator-log for fornecida, as contagens de tupla serão incluídas nos logs JSON baseados em texto e estruturados produzidos pelo comando. (Isso pode ser útil para a otimização de desempenho de um código QL complexo).

--timeout=<seconds>

[Avançado] Defina o tempo limite para a avaliação da consulta, em segundos.

O recurso de tempo limite se destina a capturar casos em que uma consulta complexa levará um tempo prologado indeterminado para ser avaliada. Não é uma forma eficaz de limitar o tempo total que a avaliação de consulta pode levar. A avaliação terá permissão para continuar, desde que cada parte cronometrada separadamente da computação seja concluída dentro do tempo limite. Atualmente, essas partes cronometradas separadamente são "camadas de RA" da consulta otimizada, mas isso poderá mudar no futuro.

Se nenhum tempo limite for especificado ou for fornecido como 0, nenhum tempo limite será definido (exceto codeql test run, sendo que o tempo limite padrão é de cinco minutos).

-j, --threads=<num>

Use esse número de threads para avaliar as consultas.

O valor padrão é 1. Você pode transmitir 0 para usar um thread por núcleo no computador ou -N para manter N núcleos não utilizados (com a exceção de que ainda será usado, pelo menos, um thread).

Opções para controlar a saída de logs estruturados do avaliador

--evaluator-log=<file>

[Avançado] Saída de logs estruturados sobre o desempenho do avaliador para o arquivo especificado. O formato desse arquivo de log está sujeito a alterações sem aviso prévio, mas será um fluxo de objetos JSON separados por dois caracteres de nova linha (por padrão) ou um se a opção --evaluator-log-minify for transmitida. Use codeql generate log-summary <file> para produzir um resumo mais estável desse arquivo e evitar a análise direta dele. O arquivo será substituído se ele já existir.

--evaluator-log-minify

[Avançado] Se a opção --evaluator-log for transmitida, também transmitir essa opção minimizará o tamanho do log JSON produzido, em detrimento de torná-lo muito menos legível por humanos.

Opções para verificar o TRAP importado

--[no-]check-undefined-labels

[Avançado] Relate os erros de rótulos indefinidos.

--[no-]check-unused-labels

[Avançado] Relate os erros de rótulos não utilizados.

--[no-]check-repeated-labels

[Avançado] Relate os erros de rótulos repetidos.

--[no-]check-redefined-labels

[Avançado] Relate os erros de rótulos redefinidos.

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

[Avançado] Relate os erros de rótulos usados antes de serem definidos.

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

[Avançado] Gere uma saída diferente de zero se ocorrer um erro durante a importação do TRAP.

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

[Avançado] Construa IDs de entidade que codificam o local no arquivo TRAP de origem. Pode ser útil para a depuração de geradores TRAP, mas ocupa muito espaço no conjunto de dados.

--[no-]linkage-aware-import

[Avançado] Controla se a importação do conjunto de dados codeql é compatível com vinculação (padrão) ou não. Em projetos em que essa parte da criação de banco de dados consome muita memória, desabilitar essa opção pode ajudá-los a progredir às custas da integridade do banco de dados.

Disponível desde v2.15.3.

Opções comuns

-h, --help

Mostre este texto de ajuda.

-J=<opt>

[Avançado] Forneça a opção para a JVM que executa o comando.

(Use-a com cautela, pois as opções que contêm espaços não serão tratadas corretamente.)

-v, --verbose

Aumente incrementalmente o número de mensagens de progresso impressas.

-q, --quiet

Diminua incrementalmente o número de mensagens de progresso impressas.

--verbosity=<level>

[Avançado] Defina explicitamente o nível de detalhamento como erros, avisos, progresso, progresso+, progresso++ ou progresso+++. Substitui -v e -q.

--logdir=<dir>

[Avançado] Escreva logs detalhados em um ou mais arquivos no diretório fornecido, com nomes gerados que incluem carimbos de data/hora e o nome do subcomando em execução.

(Para gravar um arquivo de log com um nome sobre o qual você tem controle completo, forneça --log-to-stderr e redirecione stderr conforme desejado.)

--common-caches=<dir>

[Avançado] Controle a localização dos dados armazenados em cache no disco que persistirão entre várias execuções da CLI, como pacotes QL baixados e planos de consulta compilada. Se não for definido explicitamente, o padrão corresponde a um diretório intitulado .codeql no diretório inicial do usuário; que será criado se ainda não existir.

Disponível desde v2.15.2.