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

--insecure-host

Opcional: Permitir conexão insegura ao servidor da API Bencher.

Essa flag é útil quando você está se conectando a uma instância self-hosted do Bencher com um certificado autoassinado ou um certificado que não está incluído no armazenamento de certificados do sistema. É aplicável apenas para conexões HTTPS, já que conexões HTTP são inerentemente inseguras.

AVISO: Use --insecure-host apenas em uma rede segura com fontes verificadas, pois isso ignora a verificação SSL e pode expor você a ataques de intermediário.

--native-tls

Opcional: Carregar certificados TLS do armazenamento de certificados nativo da plataforma.

Por padrão, o bencher carrega certificados do webpki-roots crate incorporado. Os webpki-roots são um conjunto confiável de raízes de confiança da Mozilla, e incluí-los no bencher melhora a portabilidade e o desempenho. Isso é especialmente verdadeiro no macOS, onde a leitura do armazenamento de confiança do sistema gera um atraso significativo.

No entanto, em alguns casos, você pode querer usar o armazenamento de certificados nativo da plataforma, especialmente se estiver contando com uma raiz de confiança corporativa incluída no armazenamento de certificados do seu sistema para um proxy obrigatório ou conexões autoassinadas do Bencher Self-Hosted.

--timeout <SECONDS>

Opcional: Timeout da requisição em segundos. O padrão é 15 segundos.

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