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.

Options

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

--start-point <BRANCH>

--start-point-hash <HASH>

--start-point-max-versions <COUNT>

--start-point-clone-thresholds

--start-point-reset

Veja seleção de branch para uma visão 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.

--threshold-measure <MEASURE>

--threshold-test <TEST>

--threshold-min-sample-size <SAMPLE_SIZE>

--threshold-max-sample-size <SAMPLE_SIZE>

--threshold-window <WINDOW>

--threshold-lower-boundary <BOUNDARY>

--threshold-upper-boundary <BOUNDARY>

--thresholds-reset

--err

Veja limiares e alertas para uma visão geral completa.

--adapter <ADAPTER>

--average <AVERAGE>

--file <FILE>

--build-time

--file-size <FILE>

Veja adaptador de benchmark para uma visão geral completa.

--iter <COUNT>

Opcional: Número de iterações de execução. O padrão é 1.

--fold <AGGREGATE_FUNCTION>

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

--format <FORMAT>

Opcional: Formato para o Relatório final. O padrão é human.

Valores possíveis:

• human: Formato legível para humanos
• json: Formato JSON
• html: 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: Defina o token de autenticação da API do GitHub. A maneira mais conveniente de fazer isso é usando a variável de ambiente GITHUB_TOKEN do GitHub Actions (ou seja, --github-actions ${{ secrets.GITHUB_TOKEN }}). Quando esta opção é definida e bencher run é usado no GitHub Actions como parte de um pull request, os resultados serão adicionados ao pull request como um comentário. Isso requer que o token tenha o escopo de pull-requests com permissões de write. Caso contrário, os resultados serão adicionados ao commit como uma Verificação do GitHub. Isso requer que o token tenha o escopo de checks com permissões de write. Em ambos os casos, os resultados também serão adicionados ao resumo do trabalho.

🐰 Se você estiver executando dentro de um contêiner Docker no GitHub Action, 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
• GITHUB_SHA

--ci-only-thresholds

Opcional: Somente publique resultados no CI se um Limite existir para o Branch, Testbed e Medida. Se não existirem Limites, nada será publicado. Requer: --github-actions

--ci-only-on-alert

Opcional: Comece a enviar resultados para CI apenas se um Alerta for gerado. Se um Alerta for gerado, todos os resultados subsequentes também serão enviados, mesmo que não contenham nenhum Alerta. Requer: --github-actions

--ci-id <ID>

Opcional: ID personalizado para publicar resultados no CI.
Por padrão, o Bencher irá automaticamente segmentar os resultados pela combinação de: Projeto, Branch, Ambiente de Teste e Adaptador.
Definir um ID personalizado é útil quando o Bencher está sendo executado várias vezes no mesmo fluxo de trabalho de CI para a mesma combinação de Projeto, Branch, Ambiente de Teste e Adaptador.
Requer: --github-actions

--ci-number <NUMBER>

Opcional: Número da issue para postar resultados no CI. O Bencher fará o possível para detectar o número da issue de CI necessário para postar resultados. No entanto, isso nem sempre está disponível em configurações complexas, como ao usar workflow_run no GitHub Actions. Requer: --github-actions

--shell <SHELL>

Opcional: Caminho para o comando do shell.
O padrão é /bin/sh em ambientes Unix-like e cmd no Windows.

--flag <FLAG>

Opcional: Flag de comando no shell. Padrão é -c em ambientes tipo Unix 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 do backend. Padrão para Bench Cloud: https://api.bencher.dev

--attempts <COUNT>

Opcional: Máximo de tentativas de novas tentativas de solicitação. O padrão é 10 tentativas.

--retry-after <SECONDS>

Opcional: Segundos iniciais para aguardar entre as tentativas (recuo exponencial). O padrão é 1 segundo.

--dry-run

Opcional: Execute uma simulação. Isso não armazenará nenhum dado no backend. Nem um Relatório, um Branch (conforme detalhado em seleção de branch), nem um Testbed será criado.

--help

Opcional: Imprime a ajuda.

🐰 Parabéns! Você aprendeu os fundamentos de bencher run! 🎉

Continuar: Seleção de Branch com bencher run ➡