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 Leistungsregressionen in Pull Requests zu erkennen, müssen Sie Ihre Benchmarks auf PRs ausführen.
Wenn Sie nur erwarten, PRs von Branches innerhalb desselben Repositorys zu haben,
können Sie einfach einen weiteren Workflow erstellen, um on
-pull_request
-Ereignisse aus demselben Repository auszuführen.
⚠️ Diese Lösung funktioniert nur, wenn alle PRs aus dem selben Repository stammen! Siehe [Pull Requests von Forks][pull requests von forks] unten.
-
Erstellen Sie eine GitHub Actions
workflow
-Datei. (z. B.:.github/workflows/pr_benchmarks.yml
) -
Führen Sie bei
pull_request
-Ereignissen aus:opened
- Ein Pull-Request wurde erstellt.reopened
- Ein zuvor geschlossener Pull-Request wurde wiedereröffnet.edited
- Der Titel oder der Text eines Pull-Requests wurde bearbeitet oder der Basis-Branch eines Pull-Requests wurde geändert.synchronize
- Der Head-Branch eines Pull-Requests wurde aktualisiert. Zum Beispiel wurde der Head-Branch vom Basis-Branch aktualisiert oder neue Commits wurden in den 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
) -
Führen Sie bei
pull_request
-Ereignissen aus, wenn und nur dann, wenn der Pull-Request aus demselben Repository stammt. ⚠️ ENTFERNEN SIE DIESE ZEILE NICHT! Für den Umgang mit Fork-PRs siehe [Pull Requests von Forks][pull requests von forks] unten. (z. B.:if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
) -
Setzen Sie die Berechtigungen für das
GITHUB_TOKEN
aufwrite
fürpull-requests
. Je nach Ihren GitHub-Einstellungen ist dies möglicherweise nicht erforderlich. Aber für alle nach dem 02. Februar 2023 erstellten Organisationen und persönlichen Repos, ist dies das Standardverhalten. Siehe die GitHub-Dokumentation für einen vollständigen Überblick. (z. B.:permissions: pull-requests: write
) -
Legen Sie den Maschinentyp fest, auf dem der Job ausgeführt werden soll. 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 das Bencher CLI mithilfe der GitHub Action. (z. B.:
uses: bencherdev/bencher@main
) -
Verwenden Sie das
bencher run
CLI-Unterkommando, um Ihre Pull-Request-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 Projekt-Slug. Siehe die--project
-Dokumentation für weitere Details. (z. B.:--project save-walter-white-1234abcd
) -
Setzen Sie die
--token
-Option auf dasBENCHER_API_TOKEN
Repository-Secret. 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 mithilfe des GitHub Actionsgithub
Kontexts. 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 mithilfe des GitHub Actionsgithub
Kontexts. 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 Startpunkts des PR-Branches mithilfe des GitHub Actionspull_request
Ereignisses. 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 Schwellenwerte 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 verhindert ein Abweichen der Benchmark-Daten. 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 weitere Details. (z. B.:--testbed ubuntu-latest
) -
Setzen Sie das
--err
-Flag, um den Befehl fehlschlagen zu lassen, wenn eine Warnung generiert wird. Siehe die--err
-Dokumentation 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-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, mithilfe der GitHub ActionsGITHUB_TOKEN
Umgebungsvariable. Siehe die--github-actions
-Dokumentation für weitere Details. (z. B.:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
Geben Sie die Argumente des Benchmark-Befehls an. Siehe Benchmark-Befehl für einen vollständigen Überblick. (z. B.:
bencher mock
)
Um den PR-Branch nach dem Schließen des PR aufzuräumen,
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ührung bei
pull_request
-Ereignissen:closed
- Ein Pull Request wurde geschlossen.
Lesen Sie 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ührung bei
pull_request
-Ereignissen nur, wenn der Pull Request aus demselben Repository stammt. ⚠️ ENTFERNEN SIE NICHT DIESE ZEILE! Weitere Informationen zum Umgang mit Fork-PRs finden Sie weiter unten unter Pull Requests von Forks. (z.B.:if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
) -
Legen Sie den Maschinentyp fest, auf dem der Job ausgeführt werden soll. Lesen Sie 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 über die 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 das Projektslug. Siehe die--project
Dokumentation für mehr 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 mehr Details. (z.B.:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Setzen Sie die
--branch
Option auf den Namen des PR-Branches mit dem GitHub Actionsgithub
Kontext. (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 zweiter 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 die Schlussfolgerung des vorherigen Workflows erfolgreich war, mithilfe
des GitHub Actions
workflow_run
Ereignisses. (z.B.:if: github.event.workflow_run.conclusion == 'success'
) - 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
) - Setzen Sie die Benchmark-Ergebnisse und
pull_request
Event-Objekt-Dateinamen als Umgebungsvariablen. (z.B.:env: ...
) - Laden Sie die zwischengespeicherten Benchmark-Ergebnisse und
pull_request
Event herunter, mithilfe deraction-download-artifact
GitHub Action. (z.B.:uses: dawidd6/action-download-artifact@v6
) - Exportieren Sie die notwendigen Daten aus dem
pull_request
Event als Umgebungsvariablen. (z.B.:core.exportVariable(...)
) - Installieren Sie die Bencher CLI, verwenden Sie die GitHub Action.
(z.B.:
uses: bencherdev/bencher@main
) - Verwenden Sie den
bencher run
CLI-Unterbefehl, um Ihre Fork Pull Branch Benchmarks zu verfolgen. Siehe denbencher run
CLI-Unterbefehl für einen vollständigen Überblick. (z.B.:bencher run
) - Setzen Sie die
--project
Option auf den Projekt-Slug. 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 Fork-PR-Branch-Namen mithilfe [des GitHub Actionsgithub
Kontext][github actions context]. Siehe die--branch
Dokumentation für einen vollständigen Überblick. (z.B.:--branch '${{ env.PR_HEAD }}'
) - Setzen Sie den Startpunkt für den Fork PR Branch:
- Setzen Sie die
--start-point
Option auf den Startpunkt des Fork PR Branch mithilfe [des GitHub Actionsgithub
Kontext][github actions context]. Siehe die--start-point
Dokumentation für einen vollständigen Überblick. (z.B.:--start-point '${{ env.PR_BASE }}'
) - Setzen Sie die
--start-point-hash
Option auf den Startpunkt-Git-Hash des Fork PR Branch mithilfe des GitHub Actionspull_request
Ereignis. Siehe die--start-point-hash
Dokumentation für einen vollständigen Überblick. (z.B.:--start-point-hash '${{ env.PR_BASE_SHA }}'
) - Setzen Sie das
--start-point-clone-thresholds
Flag, um die Schwellenwerte 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 Fork PR Branch immer auf den Startpunkt zurückzusetzen. Dies wird Datenabweichungen 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 Testbed-Namen. Dies sollte wahrscheinlich mit der inruns-on
ausgewählten Maschine übereinstimmen. Siehe die--testbed
Dokumentation für mehr Details. (z.B.:--testbed ubuntu-latest
) - Setzen Sie das
--err
Flag, um den Befehl zum Scheitern zu bringen, 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-Authentifizierungs-Token, um die Ergebnisse als Kommentar in der Pull-Anfrage zu posten, mithilfe 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-Anfrage-Nummer. Siehe die--ci-number
Dokumentation für mehr Details. (z.B.:--ci-number '${{ env.PR_NUMBER }}'
) - Setzen Sie die
--file
Option auf den Datei-Pfad der Benchmark-Ergebnisse. Siehe Benchmark-Kommando für einen vollständigen Überblick. (z.B.:--file "$BENCHMARK_RESULTS"
)
Um den Fork-PR-Branch nach dem Schließen seines PR aufzuräumen,
können Sie einen separaten Workflow erstellen, der bei on
-pull_request
-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ührung 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 umfassenden Überblick. (z.B.:on: pull_request: types: [closed]
) -
Erstellen Sie einen GitHub Actions
job
. (z.B.:jobs: archive_pr_branch
) -
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
) -
Überprüfen Sie den PR-Branch-Quellcode. (z.B.:
uses: actions/checkout@v4
) -
Installieren Sie das Bencher CLI mithilfe der GitHub Action. (z.B.:
uses: bencherdev/bencher@main
) -
Verwenden Sie das CLI-Unterkommando
bencher archive
, um den PR-Branch zu archivieren. (z.B.:bencher archive
) -
Setzen Sie die
--project
-Option auf das Projekt-Slug. Siehe die Dokumentation zur--project
Option für weitere Details. (z.B.:--project save-walter-white-1234abcd
) -
Setzen Sie die
--token
-Option auf das Repository-GeheimnisBENCHER_API_TOKEN
. Siehe die Dokumentation zur--token
Option für weitere Details. (z.B.:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Setzen Sie die
--branch
-Option auf den Namen des PR-Branchs mithilfe des GitHub Actionsgithub
Kontexts. (z.B.:--branch '${{ github.head_ref }}'
)
🐰 Glückwunsch! Sie haben gelernt, wie man Bencher in GitHub Actions verwendet! 🎉