Sous-commande CLI bencher run


bencher run est la sous-commande CLI la plus utilisée. Elle est utilisée pour exécuter des benchmarks et en rapporter les résultats. De ce fait, c’est l’une des sous-commandes les plus compliquées. Cette page expliquera les options, flags, et arguments qui peuvent être passés à bencher run.

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

Commande de Benchmark

Le premier argument à bencher run est la commande de benchmark optionnelle. C’est la commande qui sera exécutée, invoquant votre harnais de benchmark. Elle peut également être définie en utilisant la variable d’environnement BENCHER_CMD. Par défaut, cette commande est exécutée dans un shell, qui peut être configuré avec les options --shell et --flag. Sa sortie est analysée par un adaptateur de harnais de benchmark, qui peut être défini en utilisant l’option --adapter. Cependant, si le harnais de benchmark sort vers un fichier alors l’option --file doit également être utilisée pour spécifier le chemin du fichier de sortie.

Si vous préférez ne pas avoir la commande exécutée dans un shell, vous pouvez utiliser le drapeau --exec ou simplement fournir des arguments supplémentaires à votre commande en tant qu’arguments supplémentaires à bencher run.

Forme Shell :

Terminal window
bencher run "bencher mock"

Forme Exec :

Terminal window
bencher run bencher mock

La commande de benchmark peut être exécutée plusieurs fois en utilisant l’option --iter, et ces résultats peuvent être regroupés en un seul résultat en utilisant l’option --fold. Si l’une des itérations échoue, alors la commande entière est considérée comme ayant échoué à moins que le drapeau --allow-failure soit défini.

Si la commande de benchmark n’est pas spécifiée mais que l’option --file l’est, alors bencher run lira à partir du chemin du fichier de sortie à la place. Si ni la commande de benchmark ni l’option --file ne sont spécifiées, alors bencher run lira à partir de stdin à la place. Cela vous permet d’enregistrer la sortie d’une autre commande dans un fichier ou de la faire passer dans bencher run, respectivement.

Options

--project <PROJECT>


Soit l’option --project soit la variable d’environnement BENCHER_PROJECT doit être définie sur le slug ou UUID d’un projet déjà existant. Si les deux sont définis, l’option --project a la priorité sur la variable d’environnement BENCHER_PROJECT.


--token <TOKEN>


Soit l’option --token soit la variable d’environnement BENCHER_API_TOKEN doit être définie sur un token API valide. Si les deux sont définis, l’option --token a la priorité sur la variable d’environnement BENCHER_API_TOKEN.


--branch <BRANCH>

--if-branch <BRANCH_NAME>

--else-if-branch <BRANCH_NAME>

--else-branch

--endif-branch


Voir sélection de branche pour un aperçu complet.


--hash <HASH>


Optionnel : Un hash de commit SHA-1 de 40 caractères. Si deux rapports ont la même branche et hash, ils seront considérés comme provenant du même commit. Donc, ils auront le même numéro de version de branche.


--testbed <TESTBED>


Optionnel : Soit l’option --testbed soit la variable d’environnement BENCHER_TESTBED peut être définie sur le slug ou UUID d’un banc d’essai déjà existant. Si les deux sont définis, l’option --testbed a la priorité sur la variable d’environnement BENCHER_TESTBED. Si aucun n’est défini, alors localhost est utilisé comme banc d’essai par défaut.


--adapter <ADAPTER>

--average <AVERAGE>

--file <FILE>


Voir adaptateur de harnais benchmark pour un aperçu complet.


--iter <ITER>


Optionnel : Nombre d’itérations d’exécution. La valeur par défaut est 1.


--fold <FOLD>


Optionnel : Replier plusieurs résultats en un seul résultat.
Nécessite : --iter doit être défini.
Valeurs possibles :

  • min : Valeur minimale
  • max : Valeur maximale
  • mean : Moyenne des valeurs
  • median : Médiane des valeurs

--backdate <DATETIME_SECONDS>


Optionnel : Antidater le rapport (secondes depuis l’époque). NOTE : Cela n’affectera pas l’ordre des rapports passés ! C’est utile lors de l’initialisation des données historiques dans un projet lors de l’importation en ordre chronologique.


--allow-failure


Optionnel : Autorise l’échec du test de benchmark.


--err


Optionnel : Erreur lorsqu’une alerte est générée. Voir seuils et alertes pour un aperçu complet.


--html


Optionnel : Affiche les résultats en format HTML.


--quiet


Optionnel : Mode silencieux, ne produit que le JSON du rapport final. Par défaut, c’est false.


--ci-no-metrics


Optionnel: Omettre les Mesures de Référence et les Limites Limitrophes. Nécessite : --github-actions


--ci-only-thresholds


Optionnel : Publie les résultats seulement sur CI si un Seuil existe pour le types de mesures, Branche et Banc d’essai. Si aucun Seuils n’existent, alors rien ne sera posté. Nécessite : --github-actions


--ci-only-on-alert


Optionnel : Commence à poster les résultats sur CI seulement si une Alerte est générée. Si une Alerte est générée, alors les résultats suivants, même s’ils ne contiennent pas d’Alertes, seront également postés. Nécessite : --github-actions


--ci-id


Optionnel : ID personnalisé pour poster les résultats sur CI. Par défaut, Bencher segmentera automatiquement les résultats par la combinaison de : Projet, Branche, Banc d’essai, et Adaptateur. Définir un ID personnalisé est utile lorsque Bencher est exécuté plusieurs fois dans la même workflow CI pour la même combinaison de Projet, Branche, Banc d’essai, et Adaptateur. Nécessite : --github-actions


--ci-number


Optionnel : Numéro de problème pour poster les résultats sur CI. Bencher fera de son mieux pour détecter le numéro de problème CI nécessaire pour poster les résultats. Cependant, cela n’est pas toujours disponible dans des configurations complexes, comme utiliser workflow_run dans GitHub Actions. Nécessite : --github-actions


--github-actions <GITHUB_TOKEN>


Optionnel : Définir le token d’authentification de l’API GitHub (c’est-à-dire --github-actions ${{ secrets.GITHUB_TOKEN }}). Lorsque cette option est définie et que bencher run est utilisé dans GitHub Actions dans le cadre d’une pull request, alors les résultats seront ajoutés à la pull request en tant que commentaire. La manière la plus commode de faire ceci est la variable d’environnement GITHUB_TOKEN de GitHub Actions.

🐰 Si vous exécutez à l’intérieur d’un conteneur Docker dans GitHub Action, vous aurez besoin de passer les variables d’environnement suivantes et de monter le chemin spécifié par GITHUB_EVENT_PATH :

  • GITHUB_ACTIONS
  • GITHUB_EVENT_NAME
  • GITHUB_EVENT_PATH

--shell <SHELL>


Optionnel : Chemin de la commande Shell. Par défaut à /bin/sh dans les environnements Unix et cmd sur Windows.


--flag <FLAG>


Optionnel : Flag de la commande Shell. Par défaut à -c dans les environnements Unix et /C sur Windows.


--exec


Optionnel: Exécutez la commande en tant qu’exécutable et non en tant que commande shell. Par défaut si le nombre d’arguments pour bencher run est supérieur à un.



--host <URL>


Optionnel : URL du serveur Backend. Par défaut à https://api.bencher.dev.


--attempts <ATTEMPTS>


Optionnel : Nombre maximal de tentatives de requête. Par défaut à 10.


--retry-after <RETRY_AFTER_SECONDS>


Optionnel : Réessayer la requête après le nombre de secondes donné (retard exponentiel). Par défaut à 1.


--strict


Optionnel : Analyser strictement les réponses JSON. Par défaut, c’est false. L’activation de cette fonctionnalité nécessitera des mises à jour client plus fréquentes en raison de changements incompatibles.


--dry-run


Optionnel : Effectuer une exécution à blanc. Cela ne stockera aucune donnée sur le backend. Ni un Rapport ni une Branche en détail dans sélection de branche ne seront créés.


-h

--help


Optionnel : Afficher l’aide.



🐰 Bravo! Vous avez appris les bases de bencher run ! 🎉


Continuer: Sélection de Branche avec bencher run

🤖 Ce document a été automatiquement généré par OpenAI GPT-4. Il peut ne pas être précis et peut contenir des erreurs. Si vous trouvez des erreurs, veuillez ouvrir une issue sur GitHub.