bencher run CLI-Unterbefehl


bencher run ist das beliebteste CLI-Unterkommando. Es wird verwendet, um Benchmarks auszuführen und die Ergebnisse zu berichten. Daher ist es eines der kompliziertesten Unterkommandos. Diese Seite wird die Optionen, Flags und Argumente erklären, die bencher run übergeben werden können.

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

Benchmark-Befehl

Das erste Argument für bencher run ist der optionale Benchmark-Befehl. Dies ist der Befehl, der ausgeführt wird und Ihren Benchmark-Harness aufruft. Er kann auch über die Umgebungsvariable BENCHER_CMD gesetzt werden. Standardmäßig wird dieser Befehl in einer Shell ausgeführt, welche mit den Optionen --shell und --flag konfiguriert werden kann. Seine Ausgabe wird von einem Benchmark-Harness-Adapter analysiert, der mit der Option --adapter festgelegt werden kann. Wenn der Benchmark-Harness jedoch in eine Datei ausgibt, muss auch die Option --file verwendet werden, um den Ausgabedateipfad zu spezifizieren.

Wenn Sie bevorzugen, dass der Befehl nicht in einer Shell ausgeführt wird, können Sie die --exec-Flag verwenden oder einfach zusätzliche Argumente zu Ihrem Befehl als zusätzliche Argumente zu bencher run hinzufügen.

Shell-Form:

Terminal window
bencher run "bencher mock"

Exec-Form:

Terminal window
bencher run bencher mock

Der Benchmark-Befehl kann mehrere Male mit der Option --iter ausgeführt werden, und diese Ergebnisse können mit der Option --fold zu einem einzigen Ergebnis zusammengefasst werden. Wenn eine der Iterationen fehlschlägt, gilt der gesamte Befehl als fehlgeschlagen, es sei denn, die Flag --allow-failure ist gesetzt.

Wenn der Benchmark-Befehl nicht angegeben ist, aber die --file-Option besteht, dann liest bencher run stattdessen aus dem Ausgabedateipfad. Wenn weder der Benchmark-Befehl noch die --file-Option angegeben sind, dann liest bencher run stattdessen von stdin. Dies ermöglicht es Ihnen, die Ausgabe eines anderen Befehls in eine Datei zu speichern oder in bencher run zu leiten.

Optionen

--project <PROJECT>


Entweder die Option --project oder die Umgebungsvariable BENCHER_PROJECT muss auf den Slug oder UUID eines bereits existierenden Projekts gesetzt werden. Wenn beide definiert sind, hat die Option --project Vorrang vor der Umgebungsvariable BENCHER_PROJECT.


--token <TOKEN>


Entweder die Option --token oder die Umgebungsvariable BENCHER_API_TOKEN muss auf ein gültiges API-Token gesetzt werden. Wenn beide definiert sind, hat die Option --token Vorrang vor der Umgebungsvariable BENCHER_API_TOKEN.


--branch <BRANCH>

--if-branch <BRANCH_NAME>

--else-if-branch <BRANCH_NAME>

--else-branch

--endif-branch


Siehe Branch-Auswahl für einen vollständigen Überblick.


--hash <HASH>


Optional: Ein 40-stelliger SHA-1-Commit-Hash. Wenn zwei Berichte den gleichen Branch und Hash haben, werden sie als vom selben Commit angesehen. Daher werden sie die gleiche Branch-Version Nummer haben.


--testbed <TESTBED>


Optional: Entweder die Option --testbed oder die Umgebungsvariable BENCHER_TESTBED kann auf den Slug oder UUID einer bereits existierenden Testplattform gesetzt werden. Wenn beide definiert sind, hat die Option --testbed Vorrang vor der Umgebungsvariable BENCHER_TESTBED. Wenn keine definiert sind, dann wird localhost als Standard-Testplattform verwendet.


--adapter <ADAPTER>

--average <AVERAGE>

--file <FILE>


Siehe Benchmark-Harness-Adapter für einen vollständigen Überblick.


--iter <ITER>


Optional: Anzahl der Laufiterationen. Der Standardwert ist 1.


--fold <FOLD>


Optional: Mehrere Ergebnisse in ein einziges Ergebnis zusammenfalten.
Erforderlich: --iter muss gesetzt sein.
Mögliche Werte:

  • min: Minimalwert
  • max: Maximalwert
  • mean: Mittelwert der Werte
  • median: Median der Werte

--backdate <DATETIME_SECONDS>


Optional: Das Berichtsdatum zurückdatieren (Sekunden seit der Epoche). HINWEIS: Dies wird nicht die Reihenfolge der früheren Berichte beeinflussen! Dies ist nützlich, wenn man historische Daten chronologisch in ein Projekt integriert.


--allow-failure


Optional: Benchmark-Testfehler zulassen.


--err


Optional: Fehler bei der Erzeugung eines Alarms. Siehe Schwellenwerte und Alarme für einen vollständigen Überblick.


--html


Optional: Ergebnisse im HTML-Format ausgeben.


--quiet


Optional: Leiser Modus, gibt nur das endgültige Berichts-JSON aus. Standard ist false.


--ci-no-metrics


Optional: Überspringen Sie Benchmark-Metriken und Grenzwerte. Benötigt: --github-actions


--ci-only-thresholds


Optional: Ergebnisse nur an CI posten, wenn ein Threshold für die Art der Metrik, den Branch und die Testplattform existiert. Wenn keine Schwellenwerte existieren, wird nichts gepostet. Erforderlich: --github-actions


--ci-only-on-alert


Optional: Ergebnisse nur an CI posten, wenn ein Alarm erzeugt wird. Wenn ein Alarm erzeugt wird, werden auch nachfolgende Ergebnisse, auch wenn sie keine Alarme enthalten, gepostet. Erforderlich: --github-actions



Optional: Alle Links sollten auf öffentliche URLs zeigen, die kein Login erfordern. Benötigt: --github-actions


--ci-id


Optional: Benutzerdefinierte ID für das Posten von Ergebnissen an CI. Standardmäßig segmentiert Bencher Ergebnisse automatisch nach der Kombination aus: Projekt, Branch, Testplattform und Adapter. Das Setzen einer benutzerdefinierten ID ist nützlich, wenn Bencher mehrere Male im selben CI-Workflow für die gleiche Kombination aus Projekt, Branch, Testplattform und Adapter ausgeführt wird. Erforderlich: --github-actions


--ci-number


Optional: Ausgabenummer für das Posten von Ergebnissen an CI. Bencher wird sein Bestes tun, um die für das Posten von Ergebnissen benötigte CI-Ausgabennummer zu ermitteln. Dies ist jedoch in komplexen Setups, wie bei der Verwendung von workflow_run in GitHub Actions, nicht immer verfügbar. Erforderlich: --github-actions


--github-actions <GITHUB_TOKEN>


Optional: Setzen Sie das GitHub API-Authentifizierungstoken (d.h. --github-actions ${{ secrets.GITHUB_TOKEN }}). Wenn diese Option gesetzt ist und bencher run wird in GitHub Actions als Teil eines Pull Requests verwendet, dann werden die Ergebnisse dem Pull Request als Kommentar hinzugefügt. Der bequemste Weg, dies zu tun, ist die GitHub Actions GITHUB_TOKEN Umgebungsvariable.

🐰 Wenn Sie innerhalb eines Docker-Containers in GitHub Action arbeiten, müssen Sie die folgenden Umgebungsvariablen übergeben und den Pfad einbinden, der von GITHUB_EVENT_PATH angegeben wird:

  • GITHUB_ACTIONS
  • GITHUB_EVENT_NAME
  • GITHUB_EVENT_PATH

--shell <SHELL>


Optional: Shell-Befehlspfad. Standardmäßig ist dies /bin/sh in Unix-ähnlichen Umgebungen und cmd in Windows.


--flag <FLAG>


Optional: Shell-Befehlsflag. Standardmäßig ist dies -c in Unix-ähnlichen Umgebungen und /C in Windows.


--exec


Optional: Befehl als ausführbares Programm und nicht als Shell-Befehl ausführen. Standard, wenn die Anzahl der Argumente für bencher run größer als eins ist.



--host <URL>


Optional: Backend-Host-URL. Standardmäßig ist dies https://api.bencher.dev.


--attempts <ATTEMPTS>


Optional: Max. Anzahl der Wiederholungsversuche der Anfrage. Standardmäßig ist dies 10.


--retry-after <RETRY_AFTER_SECONDS>


Optional: Anfrage nach der angegebenen Anzahl von Sekunden erneut versuchen (exponentielles Backoff). Standardmäßig ist dies 1.


--strict


Optional: Strenges Parsen von JSON-Antworten. Standard ist false. Das Aktivieren dieser Funktion erfordert aufgrund von Breaking Changes häufigere Client-Updates.


--dry-run


Optional: Trockenlauf durchführen. Dies speichert keine Daten im Backend. Weder ein Bericht noch ein Branch, wie in der Branch-Auswahl detailliert beschrieben, werden erstellt.


-h

--help


Optional: Hilfe anzeigen.



🐰 Glückwunsch! Sie haben die Grundlagen von bencher run gelernt! 🎉


Weitermachen: Branch-Auswahl mit bencher run

🤖 Dieses Dokument wurde automatisch von OpenAI GPT-4 generiert. Es ist möglicherweise nicht korrekt und kann Fehler enthalten. Wenn Sie Fehler finden, öffnen Sie bitte ein Problem auf GitHub.