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 Benchmark

O primeiro argumento para bencher run é o comando benchmark opcional. Este é o comando que será executado, invocando seu ‘harness’ de benchmark. Ele também pode ser definido usando a variável de ambiente BENCHER_CMD. Por padrão, este comando é executado em um shell, que pode ser configurado com as opções --shell e --flag. Sua saída é analisa por um adaptador de ‘harness’ de benchmark, que pode ser definido usando a opção --adapter. No entanto, se o ‘harness’ de benchmark mandar a saída para um arquivo, então a opção --file deve ser usada para especificar o caminho do arquivo de saída.

Se preferir que o comando não seja executado em um shell, você pode usar a bandeira --exec ou simplesmente fornecer argumentos adicionais para o seu comando como argumentos adicionais para bencher run.

Formato Shell:

Terminal window
bencher run "bencher mock"

Formato Exec:

Terminal window
bencher run bencher mock

O comando de benchmark pode ser executado várias vezes usando a opção --iter, e esses resultados podem ser agrupados em um único resultado usando a opção --fold. Se qualquer uma das iterações falhar, então o comando inteiro é considerado como falhado a menos que a bandeira --allow-failure seja definida.

Se o comando de benchmark não for especificado, mas a opção --file for, então bencher run lerá a partir do caminho do arquivo de saída. Se nem o comando de benchmark nem a opção --file forem especificados, então bencher run lerá da stdin. Isso permite que você salve a saída de outro comando para um arquivo ou a canalize para bencher run, respectivamente.

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>

--if-branch <BRANCH_NAME>

--else-if-branch <BRANCH_NAME>

--else-branch

--endif-branch


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.


--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>


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ínimo
  • max: Valor máximo
  • mean: Média dos valores
  • median: 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.


--html


Opcional: Saída dos resultados em formato HTML.


--quiet


Opcional: Modo silencioso, apenas produz a saída final do Relatório em JSON. O padrão é false.


--ci-no-metrics


Opcional: Omita Métricas de Benchmark e Limites de Fronteira. Necessário: --github-actions


--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


--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

--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.


--strict


Opcional: Analise estritamente as respostas JSON. O padrão é false. Habilitar este recurso exigirá atualizações de cliente mais frequentes devido a mudanças que quebram a compatibilidade.


--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! 🎉


Continuar: Seleção de Branch com bencher run

🤖 Este documento foi gerado automaticamente pelo OpenAI GPT-4. Pode não ser preciso e pode conter erros. Se você encontrar algum erro, abra um problema no GitHub.