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, um Ihr Benchmark-Harness zu starten. Er kann auch über die Umgebungsvariable BENCHER_CMD gesetzt werden. Standardmäßig wird dieser Befehl in einer Shell ausgeführt, die mit den Optionen --shell und --flag konfiguriert werden kann. Seine Ausgabe wird von einem Benchmark-Harness-Adapter geparst, der mit der Option --adapter festgelegt werden kann. Wenn das Benchmark-Harness jedoch in eine Datei schreibt, dann muss auch die Option --file verwendet werden, um den Pfad der Ausgabedatei anzugeben. Alternative, um die Größe der Ausgabedatei (z. B. Binärgröße) anstelle ihres Inhalts zu verfolgen, verwenden Sie die Option --file-size, um den Pfad der Ausgabedatei anzugeben.

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

Shell-Formular:

bencher run "bencher mock"

Ausführungsformular:

bencher run bencher mock

Der Benchmark-Befehl kann mehrmals 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, der Flag --allow-failure wird gesetzt.

Wenn der Benchmark-Befehl nicht angegeben ist, aber die Option --file verwendet wird, dann wird bencher run stattdessen einfach den Pfad der Ausgabedatei lesen. Ähnlich, wenn der Benchmark-Befehl nicht angegeben ist, aber die Option --file-size verwendet wird, dann wird bencher run einfach die Größe der Datei am angegebenen Dateipfad lesen. Wenn weder der Benchmark-Befehl, die Option --file, noch die Option --file-size angegeben sind, wird bencher run stattdessen von stdin lesen. Dies ermöglicht es Ihnen, die Ausgabe eines anderen Befehls in eine Datei zu speichern oder in bencher run zu pipen.

Options

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

--start-point <BRANCH>

--start-point-hash <HASH>

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

--start-point-clone-thresholds

--start-point-reset

Siehe Branch-Auswahl für eine vollständige Übersicht.

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

Wenn nicht angegeben, versucht die Bencher CLI, den aktuellen Git-Hash zu finden. Es beginnt mit der Suche nach einem Git-Repository im aktuellen Arbeitsverzeichnis. Wenn dies nicht erfolgreich ist, wechselt es zu seinem übergeordneten Verzeichnis und wiederholt den Vorgang bis zum Stammverzeichnis. Wenn ein Git-Repository gefunden wird, dann wird der Git-Hash des HEAD der aktuellen Branch verwendet.

--no-hash

Optional: Versucht nicht, einen git-Commit-Hash zu finden. Diese Option steht in Konflikt mit --hash und setzt dessen Standardverhalten, nach einem git-Repository zu suchen, außer Kraft.

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

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

Siehe Schwellenwerte und Benachrichtigungen für einen vollständigen Überblick.

--adapter <ADAPTER>

--average <AVERAGE>

--file <FILE>

--build-time

--file-size <FILE>

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

--iter <COUNT>

Optional: Anzahl der Laufiterationen. Der Standardwert ist 1.

--fold <AGGREGATE_FUNCTION>

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

--format <FORMAT>

Optional: Format für den abschließenden Bericht. Der Standardwert ist human.

Mögliche Werte:

• human: Mensch-lesbares Format
• json: JSON-Format
• html: HTML-Format

--quiet

Optional: Ruhemodus, gibt nur den endgültigen Bericht aus. Verwenden Sie die Option --format, um das Ausgabeformat zu ändern.

--github-actions <GITHUB_TOKEN>

Optional: Setzen Sie das GitHub API-Authentifizierungstoken. Die bequemste Methode hierfür ist die Verwendung der GitHub Actions GITHUB_TOKEN Umgebungsvariable (d.h. --github-actions ${{ secrets.GITHUB_TOKEN }}). Wenn diese Option gesetzt ist und bencher run in GitHub Actions als Teil einer Pull-Anfrage verwendet wird, dann werden die Ergebnisse als Kommentar zur Pull-Anfrage hinzugefügt. Dies erfordert, dass das Token den pull-requests Bereich mit write Berechtigungen hat. Andernfalls werden die Ergebnisse dem Commit als GitHub-Prüfung hinzugefügt. Dies erfordert, dass das Token den checks Bereich mit write Berechtigungen hat. In jedem Fall werden die Ergebnisse auch zur Zusammenfassung des Jobs hinzugefügt.

🐰 Wenn Sie innerhalb eines Docker-Containers in einer GitHub-Aktion laufen, müssen Sie die folgenden Umgebungsvariablen übergeben und den Pfad einbinden, der durch GITHUB_EVENT_PATH angegeben wird:

• GITHUB_ACTIONS
• GITHUB_EVENT_NAME
• GITHUB_EVENT_PATH
• GITHUB_SHA

--ci-only-thresholds

Optional: Veröffentlicht Ergebnisse nur in CI, wenn ein Schwellenwert existiert für den Branch, das Testbett und die Messung. Wenn keine Schwellenwerte existieren, wird nichts veröffentlicht. Erfordert: --github-actions

--ci-only-on-alert

Optional: Beginnen Sie mit dem Veröffentlichen von Ergebnissen in CI, nur wenn ein Alert generiert wird. Wenn ein Alert generiert wird, werden alle nachfolgenden Ergebnisse ebenfalls veröffentlicht, selbst wenn sie keine Alerts enthalten. Erforderlich: --github-actions

--ci-id <ID>

Optional: Benutzerdefinierte ID zum Posten von Ergebnissen an CI. Standardmäßig segmentiert Bencher die Ergebnisse automatisch anhand der Kombination von: Projekt, Branch, Testbed und Adapter. Das Festlegen einer benutzerdefinierten ID ist nützlich, wenn Bencher im gleichen CI-Workflow mehrmals für die gleiche Projekt-, Branch-, Testbed- und Adapter-Kombination ausgeführt wird. Erforderlich: --github-actions

--ci-number <NUMBER>

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

--shell <SHELL>

Optional: Pfad zum Shell-Befehl. Standardmäßig /bin/sh auf Unix-ähnlichen Umgebungen und cmd auf Windows.

--flag <FLAG>

Optional: Shell-Befehlsflagge. Standardmäßig -c in Unix-ähnlichen Umgebungen und /C auf 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: URL des Backend-Hosts.
Standardmäßig Bench Cloud: https://api.bencher.dev

--attempts <COUNT>

Optional: Maximale Anzahl von erneuten Versuchen bei Anfragen. Standardmäßig auf 10 Versuche eingestellt.

--retry-after <SECONDS>

Optional: Anfangssekunden für das Warten zwischen den Versuchen (exponentielles Backoff). Standardmäßig 1 Sekunde.

--dry-run

Optional: Führen Sie einen Probelauf durch. Dies speichert keine Daten im Backend. Weder ein Bericht, ein Branch (wie im Branch-Auswahl beschrieben) noch ein Testbed werden erstellt.

--help

Optional: Hilfe anzeigen.

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

Weitermachen: Branch-Auswahl mit bencher run ➡