Subcomando bencher run CLI

bencher run es el subcomando CLI más popular. Se usa para ejecutar benchmarks y reportar los resultados. Por lo tanto, es uno de los subcomandos más complicados. Esta página explicará las opciones, banderas y argumentos que se pueden pasar a bencher run.

bencher run [OPTIONS] [COMMAND] [ARGUMENTS...]

Comando de Benchmark

El primer argumento para bencher run es el comando de benchmark opcional. Este es el comando que se ejecutará, invocando tu arnés de referencia. También se puede establecer usando la variable de entorno BENCHER_CMD. Por defecto, este comando se ejecuta en una shell, que se puede configurar con las opciones --shell y --flag. Su salida es analizada por un adaptador del arnés de referencia, que se puede establecer usando la opción --adapter. Sin embargo, si el arnés de referencia genera salida a un archivo, entonces la opción --file también debe usarse para especificar la ruta del archivo de salida. Alternativamente, para rastrear el tamaño del archivo de salida (es decir, tamaño binario) en lugar de su contenido, usa la opción --file-size para especificar la ruta del archivo de salida.

Si prefieres que el comando no se ejecute en una shell, puedes usar la bandera --exec o simplemente proporcionar argumentos adicionales a tu comando como argumentos adicionales a bencher run.

Forma Shell:

bencher run "bencher mock"

Forma Exec:

bencher run bencher mock

El comando de benchmark se puede ejecutar múltiples veces usando la opción --iter, y esos resultados pueden ser combinados en un solo resultado usando la opción --fold. Si alguna de las iteraciones falla, entonces se considera que todo el comando ha fallado a menos que la bandera --allow-failure esté establecida.

Si el comando de benchmark no se especifica pero la opción --file sí, entonces bencher run simplemente leerá de la ruta del archivo de salida en su lugar. De manera similar, si el comando de benchmark no se especifica pero la opción --file-size sí, entonces bencher run simplemente leerá el tamaño del archivo en la ruta de archivo dada en su lugar. Si ni el comando de benchmark, la opción --file, ni la opción --file-size están especificados, entonces bencher run leerá desde stdin en su lugar. Esto te permite guardar la salida de otro comando en un archivo o canalizarlo a bencher run.

Options

--project <PROJECT>

Opcional: Se puede establecer la opción --project o la variable de entorno BENCHER_PROJECT al slug o UUID de un Proyecto. Si el valor especificado es un slug y el Proyecto no existe todavía, se creará para ti. Sin embargo, si el valor especificado es un UUID, entonces el Proyecto debe existir previamente. Si ambos están especificados, la opción --project tiene prioridad sobre la variable de entorno BENCHER_PROJECT. Si ninguno está especificado, entonces se generará un slug de Proyecto para ti basado en:

1. El nombre del directorio padre del repositorio git, si está disponible.
2. El hash corto hexadecimal de 7 dígitos para el compromiso inicial del repositorio git, si está disponible.
3. Una huella dactilar alfanumérica de 13 dígitos de la máquina local, para sistemas operativos compatibles.

Por ejemplo, un slug de Proyecto generado podría verse así: project-abc4567-wxyz123456789

Cuando se crea un nuevo Proyecto para ti, ya sea que el slug sea especificado o generado, el Proyecto debe pertenecer a una Organización. Si el usuario está autenticado, entonces el Proyecto se agrega bajo la Organización personal de ese usuario. Si el usuario no está autenticado, el Proyecto se creará bajo una nueva Organización unclaimed. Esta Organización puede luego ser claimed desde la página pública de rendimiento del Proyecto o usando el slug del Proyecto mientras se está autenticado en una invocación posterior de bencher run.

--token <TOKEN>

Opcional: Puede establecerse la opción --token o la variable de entorno BENCHER_API_TOKEN a un token de API válido. Si ambos están especificados, la opción --token tiene prioridad sobre la variable de entorno BENCHER_API_TOKEN. Si ninguno está especificado, el Proyecto debe estar no reclamado. Es decir, si ya ha reclamado un Proyecto, debe proporcionar un token de API válido. Haga clic aquí para crear un token de API.

--branch <BRANCH>

--hash <HASH>

--start-point <BRANCH>

--start-point-hash <HASH>

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

--start-point-clone-thresholds

--start-point-reset

Consulta selección de ramas para una descripción completa.

--testbed <TESTBED>

Opcional: Se puede establecer la opción --testbed o la variable de entorno BENCHER_TESTBED al nombre, slug o UUID de un Testbed. Si el valor especificado es un nombre o slug y el Testbed no existe ya, se creará para usted. Sin embargo, si el valor especificado es un UUID, entonces el Testbed debe existir ya. Si ambos son especificados, la opción --testbed tiene prioridad sobre la variable de entorno BENCHER_TESTBED. Si ninguno es especificado, entonces se usa Linux, macOS o Windows, basado en el sistema operativo del host. Si el CLI de bencher ha sido compilado para un sistema operativo diferente, entonces se usa localhost como el Testbed predeterminado.

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

Consulta umbrales y alertas para una descripción completa.

--adapter <ADAPTER>

--average <AVERAGE>

--file <FILE>

--build-time

--file-size <FILE>

See adaptador de arnés de benchmark para una visión completa.

--iter <COUNT>

Opcional: Número de iteraciones de ejecución. El valor predeterminado es 1.

--fold <AGGREGATE_FUNCTION>

Opcional: Condensa múltiples resultados en un solo resultado.
Requiere: que se establezca --iter.
Valores posibles:

• min: Valor mínimo
• max: Valor máximo
• mean: Media de valores
• median: Mediana de valores

--backdate <SECONDS>

Opcional: Retroactividad del informe (segundos desde la época) NOTA: ¡Esto no afectará el orden de los informes pasados! Esto es útil cuando inicialmente se está incorporando datos históricos a un proyecto en orden cronológico.

--allow-failure

Opcional: Permitir el fallo de la prueba de benchmark.

--format <FORMAT>

Opcional: Formato para el Reporte final. El valor predeterminado es human.

Valores posibles:

• human: Formato legible para humanos
• json: Formato JSON
• html: Formato HTML

--quiet

Opcional: Modo silencioso, solo muestra el informe final. Usa la opción --format para cambiar el formato de salida.

--github-actions <GITHUB_TOKEN>

Opcional: Establezca el token de autenticación de la API de GitHub. La forma más conveniente de hacer esto es la variable de entorno GITHUB_TOKEN de GitHub Actions (es decir, --github-actions ${{ secrets.GITHUB_TOKEN }}). Cuando esta opción está configurada y bencher run se utiliza en GitHub Actions como parte de una solicitud de extracción, los resultados se agregarán a la solicitud de extracción como un comentario. Esto requiere que el token tenga el alcance pull-requests con permisos de escritura. De lo contrario, los resultados se agregarán al commit como una Verificación de GitHub. Esto requiere que el token tenga el alcance checks con permisos de escritura. En cualquier caso, los resultados también se agregarán al resumen del trabajo.

🐰 Si está ejecutando dentro de un contenedor Docker dentro de una GitHub Action, necesitará pasar las siguientes variables de entorno y montar la ruta especificada por GITHUB_EVENT_PATH:

• GITHUB_ACTIONS
• GITHUB_EVENT_NAME
• GITHUB_EVENT_PATH
• GITHUB_SHA
• GITHUB_API_URL (GitHub Enterprise Server solamente)

--ci-only-thresholds

Opcional: Solo enviar resultados a CI si existe un Umbral para la Rama, Testbed y Medida. Si no existen Umbrales, no se enviará nada. Requiere: --github-actions

--ci-only-on-alert

Opcional: Solo comenzar a publicar resultados en CI si se genera una Alerta. Si se genera una Alerta, entonces todos los resultados subsecuentes también se publicarán incluso si no contienen ninguna Alerta. Requiere: --github-actions

--ci-id <ID>

Opcional: ID personalizado para publicar resultados en CI.
Por defecto, Bencher segmentará automáticamente los resultados según la combinación de: Proyecto, Rama, Banco de pruebas y Adaptador.
Establecer un ID personalizado es útil cuando Bencher se ejecuta múltiples veces en el mismo flujo de trabajo de CI para la misma combinación de Proyecto, Rama, Banco de pruebas y Adaptador.
Requiere: --github-actions

--ci-number <NUMBER>

Opcional: Número de issue para publicar resultados en CI. Bencher hará todo lo posible para detectar el número de issue de CI necesario para publicar resultados. Sin embargo, esto no siempre está disponible en configuraciones complejas, como el uso de workflow_run en GitHub Actions. Requiere: --github-actions

--shell <SHELL>

Opcional: Ruta del comando shell. Por defecto es /bin/sh en entornos similares a Unix y cmd en Windows.

--flag <FLAG>

Opcional: Bandera de comando de shell. Por defecto es -c en entornos similares a Unix y /C en Windows.

--exec

Opcional: Ejecuta el comando como un ejecutable no como un comando de shell. Por defecto si el número de argumentos para bencher run es mayor que uno.

--host <URL>

Opcional: URL del host del backend.
Por defecto es Bench Cloud: https://api.bencher.dev

--insecure-host

Opcional: Permitir conexión insegura al servidor API de Bencher.

Esta bandera es útil cuando te estás conectando a una instancia de Bencher Self-Hosted con un certificado autofirmado o un certificado que no está incluido en el almacén de certificados del sistema. Solo es aplicable a conexiones HTTPS, ya que las conexiones HTTP son inherentemente inseguras.

ADVERTENCIA: Solo usa --insecure-host en una red segura con fuentes verificadas, ya que omite la verificación SSL y podría exponerte a ataques de intermediario.

--native-tls

Opcional: Cargar certificados TLS desde el almacén de certificados nativo de la plataforma.

Por defecto, bencher carga certificados del paquete incluido webpki-roots crate. Los webpki-roots son un conjunto confiable de raíces de confianza de Mozilla, y al incluirlos en bencher se mejora la portabilidad y el rendimiento. Esto es especialmente cierto en macOS, donde leer el almacén de confianza del sistema genera una demora significativa.

Sin embargo, en algunos casos, puede que desees usar el almacén de certificados nativo de la plataforma, especialmente si estás confiando en una raíz de confianza corporativa que está incluida en el almacén de certificados de tu sistema para un proxy obligatorio o conexiones auto-firmadas de Bencher Self-Hosted.

--timeout <SECONDS>

Opcional: Tiempo de espera de la solicitud en segundos. El valor predeterminado es de 15 segundos.

--attempts <COUNT>

Opcional: Máximo número de intentos de reintento de solicitud. Por defecto, 10 intentos.

--retry-after <SECONDS>

Opcional: Segundos iniciales para esperar entre intentos (retroceso exponencial). Por defecto, 1 segundo.

--dry-run

Opcional: Realiza una simulación. Esto no almacenará ningún dato en el backend. Ni un Informe, Rama (como se detalla en selección de rama), ni un Banco de Pruebas serán creados.

--help

Opcional: Imprimir ayuda.

🐰 ¡Felicidades! Has aprendido los conceptos básicos de bencher run! 🎉

Continúa: Selección de Ramas con bencher run ➡