Wie man Bencher in GitHub Actions verwendet
Je nach Anwendungsfall können Sie Continuous Benchmarking in GitHub Actions für Ihre:
Stellen Sie sicher, dass Sie ein API-Token erstellt haben und es als Repository-Geheimnis mit dem Namen BENCHER_API_TOKEN
festgelegt haben, bevor Sie fortfahren!
Navigieren Sie zu Ihr Repo -> Einstellungen -> Geheimnisse und Variablen -> Aktionen -> Neues Repository-Geheimnis
.
Benennen Sie das Geheimnis BENCHER_API_TOKEN
und setzen Sie den Geheimniswert auf Ihr API-Token.
In GitHub Actions werden
Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository ausgelöst wird.
Daher müssen Sie einen Branch aus demselben Repository verwenden,
wenn Sie eines der untenstehenden Workflows mit einem Pull Request zu Ihrem Repository hinzufügen.
Wenn Sie versuchen, Bencher mit einem Pull Request von einem Fork hinzuzufügen,
dann wird das BENCHER_API_TOKEN
-Geheimnis nicht verfügbar sein.
${{ secrets.BENCHER_API_TOKEN }}
wird eine leere Zeichenfolge sein.
Basis-Branch
Ein Grundpfeiler des Statistical Continuous Benchmarking ist, eine historische Basislinie für Ihren Basis-Branch zu haben. Diese historische Basislinie kann dann verwendet werden, um Leistungsregressionen in Pull Requests zu erkennen.
- Erstellen Sie eine
workflow
-Datei für GitHub Actions. (z.B.:.github/workflows/base_benchmarks.yml
) - Ausführen bei
push
-Ereignissen zummain
-Branch. Siehe die GitHub Actionson
Dokumentation und die GitHub Actionspush
Dokumentation für einen vollständigen Überblick. (z.B.:on: push: branches: main
) - Erstellen Sie einen
job
für GitHub Actions. (z.B.:jobs: benchmark_base_branch
) - Setzen Sie die Berechtigungen für das
GITHUB_TOKEN
aufwrite
fürchecks
. (z.B.:permissions: checks: write
) - Legen Sie den Maschinentyp fest, auf dem der Job ausgeführt wird.
Siehe die GitHub Actions
runs-on
Dokumentation für einen vollständigen Überblick. (z.B.:runs-on: ubuntu-latest
) - Checken Sie Ihren Basis-Branch Quellcode aus.
(z.B.:
uses: actions/checkout@v4
) - Installieren Sie die Bencher CLI mithilfe der GitHub Action.
(z.B.:
uses: bencherdev/bencher@main
) - Verwenden Sie das
bencher run
CLI-Unterkommando, um Ihremain
-Branch Benchmarks auszuführen. Siehe dasbencher run
CLI-Unterkommando für einen vollständigen Überblick. (z.B.:bencher run
) - Setzen Sie die
--project
Option auf den Project-Slug. Siehe die--project
Doku für weitere Details. (z.B.:--project save-walter-white-1234abcd
) - Setzen Sie die
--token
Option auf das Repository-GeheimnisBENCHER_API_TOKEN
. Siehe die--token
Doku für weitere Details. (z.B.:--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Setzen Sie die
--branch
Option auf den Basis-Branch Namen. Siehe die--branch
Doku für einen vollständigen Überblick. (z.B.:--branch main
) - Setzen Sie die
--testbed
Option auf den Testbed-Namen. Dies sollte wahrscheinlich mit der inruns-on
ausgewählten Maschine übereinstimmen. Siehe die--testbed
Doku für weitere Details. (z.B.:--testbed ubuntu-latest
) - Setzen Sie den Threshold für den
main
Branch,ubuntu-latest
Testbed und daslatency
Maß:- Setzen Sie die
--threshold-measure
Option auf das eingebautelatency
Measure, das vonbencher mock
generiert wird. Siehe die--threshold-measure
Doku für weitere Details. (z.B.:--threshold-measure latency
) - Setzen Sie die
--threshold-test
Option auf einen Student’s t-Test (t_test
). Siehe die--threshold-test
Doku für einen vollständigen Überblick. (z.B.:--threshold-test t_test
) - Setzen Sie die
--threshold-max-sample-size
Option auf die maximale Stichprobengröße von64
. Siehe die--threshold-max-sample-size
Doku für weitere Details. (z.B.:--threshold-max-sample-size 64
) - Setzen Sie die
--threshold-upper-boundary
Option auf die obere Grenze von0.99
. Siehe die--threshold-upper-boundary
Doku für weitere Details. (z.B.:--threshold-upper-boundary 0.99
) - Setzen Sie die
--thresholds-reset
Flag, damit nur der angegebene Threshold aktiv ist. Siehe die--thresholds-reset
Doku für einen vollständigen Überblick. (z.B.:--thresholds-reset
)
- Setzen Sie die
- Setzen Sie die
--err
Flag, damit der Befehl fehlschlägt, wenn ein Alert generiert wird. Siehe die--err
Doku für einen vollständigen Überblick. (z.B.:--err
) - Setzen Sie die
--adapter
Option auf das Bencher Metric Format JSON (json
), das vonbencher mock
generiert wird. Siehe benchmark harness adapters für einen vollständigen Überblick. (z.B.:--adapter json
) - Setzen Sie die
--github-actions
Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als GitHub Checks Kommentar zu posten, mithilfe der GitHub ActionsGITHUB_TOKEN
Umgebungsvariable. Siehe die--github-actions
Doku für weitere Details. (z.B.:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) - Geben Sie die Argumente des Benchmark-Befehls an.
Siehe benchmark command für einen vollständigen Überblick.
(z.B.:
bencher mock
)
Pull Requests
Um Performance-Regressionen in Pull Requests zu erfassen, müssen Sie Ihre Benchmarks auf PRs ausführen. Wenn Sie nur PRs von Branches innerhalb desselben Repositories erwarten, können Sie einfach einen weiteren Workflow erstellen, der bei pull_request
-Ereignissen aus demselben Repository ausgeführt wird.
⚠️ Diese Lösung funktioniert nur, wenn alle PRs aus demselben Repository stammen! Siehe unten Pull Requests aus Forks.
-
Erstellen Sie eine GitHub Actions
workflow
-Datei. (z.B.:.github/workflows/pr_benchmarks.yml
) -
Ausführung bei
pull_request
-Ereignissen:opened
- Ein Pull Request wurde erstellt.reopened
- Ein zuvor geschlossener Pull Request wurde wieder geöffnet.edited
- Der Titel oder Inhalt eines Pull Requests wurde bearbeitet, oder der Basis-Branch eines Pull Requests wurde geändert.synchronize
- Der Head-Branch eines Pull Requests wurde aktualisiert. Beispielsweise wurde der Head-Branch vom Basis-Branch aktualisiert oder neue Commits wurden zum Head-Branch gepusht.
Siehe die GitHub Actions
on
Dokumentation und die GitHub Actionspull_request
Dokumentation für einen vollständigen Überblick. (z.B.:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Erstellen Sie einen GitHub Actions
job
. (z.B.:jobs: benchmark_pr_branch
) -
Laufen Sie bei
pull_request
-Ereignissen, wenn und nur wenn der Pull Request aus demselben Repository stammt. ⚠️ ENTFERNEN SIE NICHT DIESE ZEILE! Für die Handhabung von Fork PRs siehe unten Pull Requests aus Forks. (z.B.:if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
) -
Legen Sie die Berechtigungen für das
GITHUB_TOKEN
aufwrite
fürpull-requests
fest. Je nach Ihren GitHub-Einstellungen ist dies möglicherweise nicht erforderlich. Aber für alle Organisationen und persönlichen Repos erstellt nach dem 02. Feb 2023, ist dies das standardmäßige Verhalten. Sehen Sie die GitHub Dokumentation für einen vollständigen Überblick. (z.B.:permissions: pull-requests: write
) -
Legen Sie die Art der Maschine fest, auf der der Job läuft. Siehe die GitHub Actions
runs-on
Dokumentation für einen vollständigen Überblick. (z.B.:runs-on: ubuntu-latest
) -
Checken Sie den Quellcode des PR-Branches aus. (z.B.:
uses: actions/checkout@v4
) -
Installieren Sie die Bencher CLI mithilfe der GitHub Action. (z.B.:
uses: bencherdev/bencher@main
) -
Verwenden Sie den
bencher run
CLI-Unterbefehl, um Ihre Pull Request-Branch-Benchmarks auszuführen. Siehe denbencher run
CLI-Unterbefehl für einen vollständigen Überblick. (z.B.:bencher run
) -
Setzen Sie die
--project
-Option auf das Projekt-Slug. Siehe die--project
Dokumentation für weitere Details. (z.B.:--project save-walter-white-1234abcd
) -
Setzen Sie die
--token
-Option auf das Repository-GeheimnisBENCHER_API_TOKEN
. Siehe die--token
Dokumentation für weitere Details. (z.B.:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Setzen Sie die
--branch
-Option auf den PR-Branch-Namen unter Verwendung der GitHub ActionsGITHUB_HEAD_REF
Standard-Umgebungsvariable. Siehe die--branch
Dokumentation für einen vollständigen Überblick. (z.B.:--branch "$GITHUB_HEAD_REF"
) -
Setzen Sie den Startpunkt für den PR-Branch:
- Setzen Sie die
--start-point
-Option auf den Startpunkt des PR-Branches unter Verwendung der GitHub ActionsGITHUB_BASE_REF
Standard-Umgebungsvariable. Siehe die--start-point
Dokumentation für einen vollständigen Überblick. (z.B.:--start-point "$GITHUB_BASE_REF"
) - Setzen Sie die
--start-point-hash
-Option auf dengit
Hash des PR-Branch Startpunkts unter Verwendung der GitHub Actionspull_request
Ereignis. Siehe die--start-point-hash
Dokumentation für einen vollständigen Überblick. (z.B.:--start-point-hash '${{ github.event.pull_request.base.sha }}'
) - Setzen Sie das
--start-point-clone-thresholds
Flag, um die Thresholds vom Startpunkt zu klonen. Siehe die--start-point-clone-thresholds
Dokumentation für einen vollständigen Überblick. (z.B.:--start-point-clone-thresholds
) - Setzen Sie das
--start-point-reset
Flag, um den PR-Branch immer auf den Startpunkt zurückzusetzen. Dies wird Datenverschiebungen bei Benchmarks verhindern. Siehe die--start-point-reset
Dokumentation für einen vollständigen Überblick. (z.B.:--start-point-reset
)
- Setzen Sie die
-
Setzen Sie die
--testbed
-Option auf den Namen des Testbeds. Dies sollte wahrscheinlich auf die inruns-on
ausgewählte Maschine abgestimmt sein. Siehe die--tested
Dokumentation für mehr Details. (z.B.:--testbed ubuntu-latest
) -
Setzen Sie das
--err
Flag, um den Befehl zu beenden, wenn ein Alarm generiert wird. Siehe die--err
Dokumentation für einen vollständigen Überblick. (z.B.:--err
) -
Setzen Sie die
--adapter
-Option auf Bencher Metric Format JSON (json
), das vonbencher mock
generiert wird. Siehe Benchmark-Harness-Adapter für einen vollständigen Überblick. (z.B.:--adapter json
) -
Setzen Sie die
--github-actions
-Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als Kommentar im Pull Request zu posten, unter Verwendung der GitHub ActionsGITHUB_TOKEN
Umgebungsvariable. Siehe die--github-actions
Dokumentation für mehr Details. (z.B.:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
Geben Sie die Argumente für den Benchmark-Befehl an. Siehe Benchmark Befehl für einen vollständigen Überblick. (z.B.:
bencher mock
)
Um den PR-Branch zu bereinigen, nachdem sein PR geschlossen wurde,
können Sie einen separaten Workflow erstellen, der bei on
pull_request
-Ereignissen mit dem Typ closed
ausgeführt wird.
Dieser Workflow archiviert den PR-Branch mit dem Befehl bencher archive
.
-
Erstellen Sie eine GitHub Actions
workflow
-Datei. (z.B.:.github/workflows/pr_benchmarks_closed.yml
) -
Ausführen bei
pull_request
-Ereignissen:closed
- Ein Pull-Request wurde geschlossen.
Siehe die GitHub Actions
on
Dokumentation und die GitHub Actionspull_request
Dokumentation für einen vollständigen Überblick. (z.B.:on: pull_request: types: [closed]
) -
Erstellen Sie einen GitHub Actions
job
. (z.B.:jobs: archive_pr_branch
) -
Ausführen bei
pull_request
-Ereignissen, wenn und nur wenn der Pull-Request aus demselben Repository stammt. ⚠️ ENTFERNEN SIE DIESE ZEILE NICHT! Für die Handhabung von Fork-PRs siehe Pull Requests from Forks unten. (z.B.:if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
) -
Legen Sie den Typ der Maschine fest, auf der der Job ausgeführt wird. Siehe die GitHub Actions
runs-on
Dokumentation für einen vollständigen Überblick. (z.B.:runs-on: ubuntu-latest
) -
Checken Sie den PR-Branch-Quellcode aus. (z.B.:
uses: actions/checkout@v4
) -
Installieren Sie das Bencher CLI mit dem GitHub Action. (z.B.:
uses: bencherdev/bencher@main
) -
Verwenden Sie den
bencher archive
CLI-Unterbefehl, um den PR-Branch zu archivieren. (z.B.:bencher archive
) -
Setzen Sie die
--project
Option auf den Project-Slug. Siehe die--project
Doku für weitere Details. (z.B.:--project save-walter-white-1234abcd
) -
Setzen Sie die
--token
Option auf das Repository-GeheimnisBENCHER_API_TOKEN
. Siehe die--token
Doku für weitere Details. (z.B.:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Setzen Sie die
--branch
Option auf den PR-Branch-Namen unter Verwendung der GitHub ActionsGITHUB_HEAD_REF
Standardumgebungsvariable. (z.B.:--branch "$GITHUB_HEAD_REF"
)
Pull-Requests aus Forks
Wenn Sie planen, Pull-Requests aus Forks zu akzeptieren, wie es in öffentlichen Open-Source-Projekten oft der Fall ist,
müssen Sie die Dinge ein wenig anders handhaben.
Aus Sicherheitsgründen sind Geheimnisse wie Ihr BENCHER_API_TOKEN
und der GITHUB_TOKEN
in GitHub Actions für Fork-PRs nicht verfügbar.
Das bedeutet, dass, wenn ein externer Mitwirkender einen PR aus einem Fork öffnet, das obige Beispiel nicht funktioniert.
Siehe dieses GitHub Security Lab Artikel
und diesen Blog-Beitrag
über die Verhinderung von schädlichen Anfragen für einen vollständigen Überblick.
Dies ist der sichere und empfohlene Weg, um Kontinuierliches Benchmarking zu Fork-Pull-Requests hinzuzufügen.
Es erfordert zwei separate Workflows.
Der erste Workflow läuft und speichert die Benchmark-Ergebnisse im pull_request
-Kontext.
Keine Geheimnisse wie Ihr BENCHER_API_TOKEN
und der GITHUB_TOKEN
sind dort verfügbar.
Dann lädt ein zweiter Workflow die zwischengespeicherten Benchmark-Ergebnisse im workflow_run
-Kontext herunter und lädt sie zu Bencher hoch.
Dies funktioniert, weil workflow_run
im Kontext des Standard-Branches des Repositorys läuft,
wo Geheimnisse wie Ihr BENCHER_API_TOKEN
und der GITHUB_TOKEN
verfügbar sind.
Die Pull-Request-Nummer, der Head-Branch und der Base-Branch, die im anfänglichen pull_request
-Workflow verwendet werden,
müssen ebenfalls explizit in den workflow_run
-Workflow übergeben werden, da sie dort nicht verfügbar sind.
Diese Workflows werden nur ausgeführt, wenn sie im Standard-Branch existieren.
Siehe Verwenden von Daten aus dem auslösenden Workflow für einen vollständigen Überblick.
-
Erstellen Sie eine erste GitHub Actions
workflow
-Datei. (z.B.:.github/workflows/fork_pr_benchmarks_run.yml
) -
Benennen Sie diesen Workflow, sodass er vom zweiten Workflow referenziert werden kann. (z.B.:
name: Run Benchmarks
) -
Führen Sie diese bei
pull_request
-Ereignissen aus:opened
- Ein Pull-Request wurde erstellt.reopened
- Ein zuvor geschlossener Pull-Request wurde wieder geöffnet.edited
- Der Titel oder der Hauptteil eines Pull-Requests wurde bearbeitet oder der Basisbranch eines Pull-Requests wurde geändert.synchronize
- Der Kopfbranch eines Pull-Requests wurde aktualisiert. Zum Beispiel wurde der Kopfbranch vom Basisbranch aktualisiert oder neue Commits wurden zum Kopfbranch hinzugefügt.
Siehe die GitHub Actions
on
-Dokumentation und die GitHub Actionspull_request
-Dokumentation für einen vollständigen Überblick. (z.B.:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Erstellen Sie einen GitHub Actions
job
. (z.B.:jobs: benchmark_fork_pr_branch
) -
Legen Sie den Maschinentyp fest, auf dem der Job ausgeführt wird. Siehe die GitHub Actions
runs-on
-Dokumentation für einen vollständigen Überblick. (z.B.:runs-on: ubuntu-latest
) -
Überprüfen Sie den Quellcode des Fork PR Branch. (z.B.:
uses: actions/checkout@v4
) -
Führen Sie Ihre Benchmarks durch und speichern Sie die Ergebnisse in einer Datei. (z.B.:
/bin/echo '{ ... }' > benchmark_results.json
) -
Laden Sie die Benchmark-Ergebnisdatei als Artefakt hoch. (z.B.:
uses: actions/upload-artifact@v4
) -
Laden Sie das
pull_request
-Ereignisobjekt als Artefakt hoch. (z.B.:uses: actions/upload-artifact@v4
)
- Erstellen Sie eine erste GitHub Actions
workflow
Datei. (z. B..github/workflows/fork_pr_benchmarks_track.yml
) - Benennen Sie diesen Workflow als zweiten Workflow.
(z. B.
name: Track Benchmarks with Bencher
) - Verknüpfen Sie die beiden Workflows mit
dem
workflow_run
Ereignis. (z. B.on: workflow_run: ...
) - Erstellen Sie einen GitHub Actions
job
. (z. B.jobs: track_fork_pr_branch
) - Führen Sie diesen Job nur aus, wenn das Ergebnis des vorherigen Workflows erfolgreich war, unter Verwendung
des GitHub Actions
workflow_run
Ereignisses. (z. B.if: github.event.workflow_run.conclusion == 'success'
) - Legen Sie die Art der Maschine fest, auf der der Job ausgeführt wird.
Siehe die GitHub Actions
runs-on
Dokumentation für einen vollständigen Überblick. (z. B.runs-on: ubuntu-latest
) - Setzen Sie die Benchmark-Ergebnisse und die Dateinamen des
pull_request
Ereignisobjekts als Umgebungsvariablen. (z. B.env: ...
) - Laden Sie die zwischengespeicherten Benchmark-Ergebnisse und das
pull_request
Ereignis herunter mit deraction-download-artifact
GitHub Action. (z. B.uses: dawidd6/action-download-artifact@v6
) - Exportieren Sie die notwendigen Daten aus dem
pull_request
Ereignis als Umgebungsvariablen. (z. B.core.exportVariable(...)
) - Installieren Sie die Bencher CLI mit der GitHub Action.
(z. B.
uses: bencherdev/bencher@main
) - Verwenden Sie den
bencher run
CLI-Unterbefehl, um die Benchmarks Ihres Fork-Pull-Zweigs zu verfolgen. Siehe denbencher run
CLI-Unterbefehl für einen vollständigen Überblick. (z. B.bencher run
) - Setzen Sie die
--project
Option auf den Projektslug. Siehe die--project
Dokumentation für mehr Details. (z. B.--project save-walter-white-1234abcd
) - Setzen Sie die
--token
Option auf dasBENCHER_API_TOKEN
Repository-Geheimnis. Siehe die--token
Dokumentation für mehr Details. (z. B.--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Setzen Sie die
--branch
Option auf den Namen des Fork-PR-Zweigs unter Verwendung einer Zwischen-Umgebungsvariablen. Siehe die--branch
Dokumentation für einen vollständigen Überblick. (z. B.--branch "$PR_HEAD"
) - Setzen Sie den Ausgangspunkt für den Fork-PR-Zweig:
- Setzen Sie die
--start-point
Option auf den Ausgangspunkt des Fork-PR-Zweigs unter Verwendung einer Zwischen-Umgebungsvariablen. Siehe die--start-point
Dokumentation für einen vollständigen Überblick. (z. B.--start-point "$PR_BASE"
) - Setzen Sie die
--start-point-hash
Option auf dengit
-Hash des Ausgangspunkts des Fork-PR-Zweigs unter Verwendung einer Zwischen-Umgebungsvariablen. Siehe die--start-point-hash
Dokumentation für einen vollständigen Überblick. (z. B.--start-point-hash "$PR_BASE_SHA"
) - Setzen Sie das
--start-point-clone-thresholds
Flag, um die Schwellenwerte vom Ausgangspunkt zu klonen. Siehe die--start-point-clone-thresholds
Dokumentation für einen vollständigen Überblick. (z. B.--start-point-clone-thresholds
) - Setzen Sie das
--start-point-reset
Flag, um den Fork-PR-Zweig immer auf den Ausgangspunkt zurückzusetzen. Dies wird Datenabweichungen der Benchmarks verhindern. Siehe die--start-point-reset
Dokumentation für einen vollständigen Überblick. (z. B.--start-point-reset
)
- Setzen Sie die
- Setzen Sie die
--testbed
Option auf den Testbed-Namen. Dies sollte wahrscheinlich mit der inruns-on
ausgewählten Maschine übereinstimmen. Siehe die--tested
Dokumentation für mehr Details. (z. B.--testbed ubuntu-latest
) - Setzen Sie das
--err
Flag, um den Befehl fehlschlagen zu lassen, wenn ein Alarm erzeugt wird. Siehe die--err
Dokumentation für einen vollständigen Überblick. (z. B.--err
) - Setzen Sie die
--adapter
Option auf Bencher Metric Format JSON (json
), das durchbencher mock
generiert wird. Siehe die Adapters für Benchmarking-Harnesses für einen vollständigen Überblick. (z. B.--adapter json
) - Setzen Sie die
--github-actions
Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als Kommentar im Pull Request zu posten, unter Verwendung der GitHub ActionsGITHUB_TOKEN
Umgebungsvariable. Siehe die--github-actions
Dokumentation für mehr Details. (z. B.--github-actions '${{ secrets.GITHUB_TOKEN }}'
) - Setzen Sie die
--ci-number
Option auf die Pull Request-Nummer unter Verwendung einer Zwischen-Umgebungsvariablen. Siehe die--ci-number
Dokumentation für mehr Details. (z. B.--ci-number "$PR_NUMBER"
) - Setzen Sie die
--file
Option auf den Dateipfad der Benchmark-Ergebnisse. Siehe Benchmark-Befehl für einen vollständigen Überblick. (z. B.--file "$BENCHMARK_RESULTS"
)
Um den Fork-PR-Branch zu bereinigen, nachdem sein PR geschlossen wurde,
können Sie einen separaten Workflow erstellen, der bei on
pull_request_target
-Ereignissen mit dem Typ closed
ausgeführt wird.
Dieser Workflow archiviert den Fork-PR-Branch mit dem Befehl bencher archive
.
-
Erstellen Sie eine GitHub Actions
workflow
-Datei. (z.B.:.github/workflows/fork_pr_benchmarks_closed.yml
) -
Ausführen bei
pull_request_target
-Ereignissen:closed
- Ein Pull-Request wurde geschlossen.
Siehe die GitHub Actions
on
Dokumentation und GitHub Actionspull_request_target
Dokumentation für einen vollständigen Überblick. (z.B.:on: pull_request_target: types: [closed]
) -
Erstellen Sie einen GitHub Actions
job
. (z.B.:jobs: archive_pr_branch
) -
Legen Sie den Maschinentyp fest, auf dem der Job ausgeführt wird. Siehe die GitHub Actions
runs-on
Dokumentation für einen vollständigen Überblick. (z.B.:runs-on: ubuntu-latest
) -
Checken Sie den Quellcode des PR-Branches aus. (z.B.:
uses: actions/checkout@v4
) -
Installieren Sie die Bencher CLI mit der GitHub Action. (z.B.:
uses: bencherdev/bencher@main
) -
Verwenden Sie den
bencher archive
CLI-Unterbefehl, um den PR-Branch zu archivieren. (z.B.:bencher archive
) -
Setzen Sie die
--project
Option auf den Projektslug. Siehe die--project
Dokumentation für weitere Details. (z.B.:--project save-walter-white-1234abcd
) -
Setzen Sie die
--token
Option auf das Repository-GeheimnisBENCHER_API_TOKEN
. Siehe die--token
Dokumentation für weitere Details. (z.B.:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Setzen Sie die
--branch
Option auf den PR-Branch-Namen unter Verwendung der GitHub ActionsGITHUB_HEAD_REF
Standard-Umgebungsvariable. (z.B.:--branch "$GITHUB_HEAD_REF"
)
🐰 Glückwunsch! Sie haben gelernt, wie man Bencher in GitHub Actions verwendet! 🎉