Subcomando bencher run CLI
bencher run
é o subcomando CLI mais popular. É usado para executar benchmarks e reportar os resultados. Por isso, é um dos subcomandos mais complicados. Esta página vai explicar as opções, flags e argumentos que podem ser passados para bencher run
.
bencher run [OPTIONS] [COMMAND] [ARGUMENTS...]
Comando de Benchmark
O primeiro argumento para bencher run
é o comando de benchmark opcional.
Este é o comando que será executado, invocando seu mecanismo de benchmark.
Ele também pode ser definido usando a variável de ambiente BENCHER_CMD
.
Por padrão, esse comando é executado em um shell,
o qual pode ser configurado com as opções --shell
e --flag
.
Seu output é analisado por um adaptador de mecanismo de benchmark,
que pode ser definido usando a opção --adapter
.
No entanto, se o mecanismo de benchmark gerar saída para um arquivo, então a opção --file
também deve ser usada para especificar o caminho do arquivo de saída.
Alternativamente, para acompanhar o tamanho do arquivo de saída (ou seja, o tamanho do binário) em vez de seu conteúdo,
use a opção --file-size
para especificar o caminho do arquivo de saída.
Se você preferir não ter o comando executado em um shell, você pode usar a flag --exec
ou simplesmente fornecer argumentos adicionais ao seu comando como argumentos adicionais para bencher run
.
Forma Shell:
bencher run "bencher mock"
Forma Exec:
bencher run bencher mock
O comando de benchmark pode ser executado várias vezes usando a opção --iter
,
e esses resultados podem ser consolidados em um único resultado usando a opção --fold
.
Se alguma das iterações falhar, então o comando inteiro é considerado como falho
a menos que a flag --allow-failure
seja definida.
Se o comando de benchmark não for especificado mas a opção --file
for,
então bencher run
apenas lerá do caminho do arquivo de saída.
Similarmente, se o comando de benchmark não for especificado mas a opção --file-size
for,
então bencher run
apenas lerá o tamanho do arquivo no caminho do arquivo especificado.
Se nem o comando de benchmark, a opção --file
,
nem a opção --file-size
forem especificados,
então bencher run
lerá de stdin
em vez disso.
Isso permite que você salve a saída de outro comando em um arquivo ou o encaminhe para bencher run
.
Opções
--project <PROJECT>
A opção --project
ou a variável de ambiente BENCHER_PROJECT
deve ser configurada para o slug ou UUID de um projeto já existente.
Se ambos estiverem definidos, a opção --project
tem precedência sobre a variável de ambiente BENCHER_PROJECT
.
--token <TOKEN>
A opção --token
ou a variável de ambiente BENCHER_API_TOKEN
deve ser configurada para um token API válido.
Se ambos estiverem definidos, a opção --token
tem precedência sobre a variável de ambiente BENCHER_API_TOKEN
.
--branch <BRANCH>
--branch-start-point <BRANCH>
--branch-start-point-hash <HASH>
--branch-reset
Veja seleção de branch para uma visão geral completa.
--hash <HASH>
Opcional: Um hash de commit SHA-1 de 40 caracteres. Se dois relatórios possuírem a mesma branch e hash, eles serão considerados do mesmo commit. Portanto, eles vão ter o mesmo número de versão da branch.
Se não for fornecido, o Bencher CLI tenta encontrar o hash git atual. Ele começa procurando por um repositório git no diretório de trabalho atual. Se não for bem-sucedido, ele continua para o diretório pai e tenta novamente até o diretório raiz. Se um repositório git for encontrado, então o hash git HEAD da branch atual é usado.
--no-hash
Opcional: Não tentar encontrar um hash de commit
do git
.
Esta opção entra em conflito com --hash
e sobrepõe seu comportamento padrão de buscar por um repositório do git
.
--testbed <TESTBED>
Opcional: A opção --testbed
ou a variável de ambiente BENCHER_TESTBED
pode ser configurada para o slug ou UUID de um testbed já existente.
Se ambos estiverem definidos, a opção --testbed
tem precedência sobre a variável de ambiente BENCHER_TESTBED
.
Se nenhum dos dois estarem definidos, então localhost
é usado como o testbed padrão.
--adapter <ADAPTER>
--average <AVERAGE>
--file <FILE>
--file-size <FILE>
Veja adaptador de benchmark para uma visão geral completa.
--iter <ITER>
Opcional: Número de iterações de execução. O padrão é 1
.
--fold <FOLD>
Opcional: Combine vários resultados em um único resultado.
Requer: --iter
definido.
Valores possíveis:
min
: Valor mínimomax
: Valor máximomean
: Média dos valoresmedian
: Mediana dos valores
--backdate <DATETIME_SECONDS>
Opcional: Retrodata o relatório (segundos desde a época). NOTA: Isso não afetará a ordem dos relatórios passados! Isso é útil ao inicialmente inserir dados históricos em um projeto em ordem cronológica.
--allow-failure
Opcional: Permita falha no teste de benchmark.
--err
Opcional: Erro quando um alerta é gerado. Veja limiares e alertas para uma visão geral completa.
--format <FORMAT>
Opcional: Formato para o Relatório final.
O padrão é human
.
Valores possíveis:
human
: Formato legível para humanosjson
: Formato JSONhtml
: Formato HTML
--quiet
Opcional: Modo silencioso, apenas exibe o relatório final.
Use a opção --format
para alterar o formato de saída.
--github-actions <GITHUB_TOKEN>
Opcional: Configura o token de autenticação da API GitHub (ou seja, --github-actions ${{ secrets.GITHUB_TOKEN }}
).
Quando esta opção é configurada e bencher run
é usado em GitHub Actions como parte de um pull request,
os resultados serão adicionados ao pull request como um comentário.
A forma mais conveniente de fazer isso é a variável de ambiente GITHUB_TOKEN
do GitHub Actions.
🐰 Se você estiver executando dentro de um contêiner Docker dentro do GitHub Action, você precisará passar as seguintes variáveis de ambiente e montar o caminho especificado por
GITHUB_EVENT_PATH
:
GITHUB_ACTIONS
GITHUB_EVENT_NAME
GITHUB_EVENT_PATH
--ci-only-thresholds
Opcional: Somente postar resultados para CI se um Limite existir para o Tipo de Métrica, Branch e Testbed.
Se não existirem Limites, então nada será postado.
Requer: --github-actions
--ci-only-on-alert
Opcional: Comece a postar resultados para CI somente se um Alerta for gerado.
Se um Alerta for gerado, então os resultados de acompanhamento, mesmo que não contenham nenhum Alerta, também serão postados.
Requer: --github-actions
--ci-id
Opcional: ID personalizada para postar resultados para CI.
Por padrão, o Bencher irá segmentar automaticamente os resultados pela combinação de: Projeto, Branch, Testbed e Adaptador.
Definir um ID personalizado é útil quando o Bencher está sendo executado várias vezes na mesma estrutura de trabalho CI para a mesma combinação de Projeto, Branch, Testbed, e Adaptador.
Requer: --github-actions
--ci-number
Opcional: Número de problema para postar resultados para CI.
Bencher vai tentar ao máximo detectar o número do problema CI necessário para postar resultados.
No entanto, isso nem sempre está disponível em configurações complexas, como usar workflow_run
em GitHub Actions.
Requer: --github-actions
--shell <SHELL>
Opcional: Caminho do comando Shell. Por padrão é /bin/sh
em ambientes Unix-like e cmd
no Windows.
--flag <FLAG>
Opcional: Flag do comando Shell. Por padrão é -c
em ambientes Unix-like e /C
no Windows.
--exec
Opcional: Execute o comando como um executável, não como um comando de shell.
Padrão se o número de argumentos para bencher run
for maior que um.
--host <URL>
Opcional: URL do host Backend. Por padrão é https://api.bencher.dev.
--attempts <ATTEMPTS>
Opcional: Tentativas máximas de requisição. Por padrão é 10
.
--retry-after <RETRY_AFTER_SECONDS>
Opcional: Requisição de tentativa após o número dado de segundos (recuo exponencial). Por padrão é 1
.
--dry-run
Opcional: Executar uma simulação. Isso não irá armazenar nenhum dado no backend. Nem um Relatório nem Branch como detalhado em seleção de branch serão criados.
-h
--help
Opcional: Mostra a ajuda.
🐰 Parabéns! Você aprendeu os fundamentos de
bencher run
! 🎉