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.

.github/workflows/base_benchmarks.yml
on:
push:
branches: main
jobs:
benchmark_base_branch:
name: Continuous Benchmarking with Bencher
permissions:
checks: write
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: bencherdev/bencher@main
- name: Track base branch benchmarks with Bencher
run: |
bencher run \
--project save-walter-white-1234abcd \
--token '${{ secrets.BENCHER_API_TOKEN }}' \
--branch main \
--testbed ubuntu-latest \
--threshold-measure latency \
--threshold-test t_test \
--threshold-max-sample-size 64 \
--threshold-upper-boundary 0.99 \
--thresholds-reset \
--err \
--adapter json \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
bencher mock
  1. Erstellen Sie eine workflow-Datei für GitHub Actions. (z.B.: .github/workflows/base_benchmarks.yml)
  2. Ausführen bei push-Ereignissen zum main-Branch. Siehe die GitHub Actions on Dokumentation und die GitHub Actions push Dokumentation für einen vollständigen Überblick. (z.B.: on: push: branches: main)
  3. Erstellen Sie einen job für GitHub Actions. (z.B.: jobs: benchmark_base_branch)
  4. Setzen Sie die Berechtigungen für das GITHUB_TOKEN auf write für checks. (z.B.: permissions: checks: write)
  5. 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)
  6. Checken Sie Ihren Basis-Branch Quellcode aus. (z.B.: uses: actions/checkout@v4)
  7. Installieren Sie die Bencher CLI mithilfe der GitHub Action. (z.B.: uses: bencherdev/bencher@main)
  8. Verwenden Sie das bencher run CLI-Unterkommando, um Ihre main-Branch Benchmarks auszuführen. Siehe das bencher run CLI-Unterkommando für einen vollständigen Überblick. (z.B.: bencher run)
  9. Setzen Sie die --project Option auf den Project-Slug. Siehe die --project Doku für weitere Details. (z.B.: --project save-walter-white-1234abcd)
  10. Setzen Sie die --token Option auf das Repository-Geheimnis BENCHER_API_TOKEN. Siehe die --token Doku für weitere Details. (z.B.: --token '${{ secrets.BENCHER_API_TOKEN }}')
  11. Setzen Sie die --branch Option auf den Basis-Branch Namen. Siehe die --branch Doku für einen vollständigen Überblick. (z.B.: --branch main)
  12. Setzen Sie die --testbed Option auf den Testbed-Namen. Dies sollte wahrscheinlich mit der in runs-on ausgewählten Maschine übereinstimmen. Siehe die --testbed Doku für weitere Details. (z.B.: --testbed ubuntu-latest)
  13. Setzen Sie den Threshold für den main Branch, ubuntu-latest Testbed und das latency Maß:
    1. Setzen Sie die --threshold-measure Option auf das eingebaute latency Measure, das von bencher mock generiert wird. Siehe die --threshold-measure Doku für weitere Details. (z.B.: --threshold-measure latency)
    2. 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)
    3. Setzen Sie die --threshold-max-sample-size Option auf die maximale Stichprobengröße von 64. Siehe die --threshold-max-sample-size Doku für weitere Details. (z.B.: --threshold-max-sample-size 64)
    4. Setzen Sie die --threshold-upper-boundary Option auf die obere Grenze von 0.99. Siehe die --threshold-upper-boundary Doku für weitere Details. (z.B.: --threshold-upper-boundary 0.99)
    5. 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)
  14. 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)
  15. Setzen Sie die --adapter Option auf das Bencher Metric Format JSON (json), das von bencher mock generiert wird. Siehe benchmark harness adapters für einen vollständigen Überblick. (z.B.: --adapter json)
  16. Setzen Sie die --github-actions Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als GitHub Checks Kommentar zu posten, mithilfe der GitHub Actions GITHUB_TOKEN Umgebungsvariable. Siehe die --github-actions Doku für weitere Details. (z.B.: --github-actions '${{ secrets.GITHUB_TOKEN }}')
  17. 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.

.github/workflows/pr_benchmarks.yml
on:
pull_request:
types: [opened, reopened, edited, synchronize]
jobs:
benchmark_pr_branch:
name: Continuous Benchmarking PRs with Bencher
# DO NOT REMOVE: For handling Fork PRs see Pull Requests from Forks
if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
permissions:
pull-requests: write
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: bencherdev/bencher@main
- name: Track PR Benchmarks with Bencher
run: |
bencher run \
--project save-walter-white-1234abcd \
--token '${{ secrets.BENCHER_API_TOKEN }}' \
--branch "$GITHUB_HEAD_REF" \
--start-point "$GITHUB_BASE_REF" \
--start-point-hash '${{ github.event.pull_request.base.sha }}' \
--start-point-clone-thresholds \
--start-point-reset \
--testbed ubuntu-latest \
--err \
--adapter json \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
bencher mock
  1. Erstellen Sie eine GitHub Actions workflow-Datei. (z.B.: .github/workflows/pr_benchmarks.yml)

  2. 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 Actions pull_request Dokumentation für einen vollständigen Überblick. (z.B.: on: pull_request: types: [opened, reopened, edited, synchronize])

  3. Erstellen Sie einen GitHub Actions job. (z.B.: jobs: benchmark_pr_branch)

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

  5. Legen Sie die Berechtigungen für das GITHUB_TOKEN auf write für pull-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)

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

  7. Checken Sie den Quellcode des PR-Branches aus. (z.B.: uses: actions/checkout@v4)

  8. Installieren Sie die Bencher CLI mithilfe der GitHub Action. (z.B.: uses: bencherdev/bencher@main)

  9. Verwenden Sie den bencher run CLI-Unterbefehl, um Ihre Pull Request-Branch-Benchmarks auszuführen. Siehe den bencher run CLI-Unterbefehl für einen vollständigen Überblick. (z.B.: bencher run)

  10. Setzen Sie die --project-Option auf das Projekt-Slug. Siehe die --project Dokumentation für weitere Details. (z.B.: --project save-walter-white-1234abcd)

  11. Setzen Sie die --token-Option auf das Repository-Geheimnis BENCHER_API_TOKEN. Siehe die --token Dokumentation für weitere Details. (z.B.: --token '${{ secrets.BENCHER_API_TOKEN }}')

  12. Setzen Sie die --branch-Option auf den PR-Branch-Namen unter Verwendung der GitHub Actions GITHUB_HEAD_REF Standard-Umgebungsvariable. Siehe die --branch Dokumentation für einen vollständigen Überblick. (z.B.: --branch "$GITHUB_HEAD_REF")

  13. Setzen Sie den Startpunkt für den PR-Branch:

    1. Setzen Sie die --start-point-Option auf den Startpunkt des PR-Branches unter Verwendung der GitHub Actions GITHUB_BASE_REF Standard-Umgebungsvariable. Siehe die --start-point Dokumentation für einen vollständigen Überblick. (z.B.: --start-point "$GITHUB_BASE_REF")
    2. Setzen Sie die --start-point-hash-Option auf den git Hash des PR-Branch Startpunkts unter Verwendung der GitHub Actions pull_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 }}')
    3. 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)
    4. 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)
  14. Setzen Sie die --testbed-Option auf den Namen des Testbeds. Dies sollte wahrscheinlich auf die in runs-on ausgewählte Maschine abgestimmt sein. Siehe die --tested Dokumentation für mehr Details. (z.B.: --testbed ubuntu-latest)

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

  16. Setzen Sie die --adapter-Option auf Bencher Metric Format JSON (json), das von bencher mock generiert wird. Siehe Benchmark-Harness-Adapter für einen vollständigen Überblick. (z.B.: --adapter json)

  17. Setzen Sie die --github-actions-Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als Kommentar im Pull Request zu posten, unter Verwendung der GitHub Actions GITHUB_TOKEN Umgebungsvariable. Siehe die --github-actions Dokumentation für mehr Details. (z.B.: --github-actions '${{ secrets.GITHUB_TOKEN }}')

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

.github/workflows/pr_benchmarks_closed.yml
on:
pull_request:
types: [closed]
jobs:
archive_pr_branch:
name: Archive closed PR branch with Bencher
# DO NOT REMOVE: For handling Fork PRs see Pull Requests from Forks
if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: bencherdev/bencher@main
- name: Archive closed PR branch with Bencher
run: |
bencher archive \
--project save-walter-white-1234abcd \
--token '${{ secrets.BENCHER_API_TOKEN }}' \
--branch "$GITHUB_HEAD_REF"
  1. Erstellen Sie eine GitHub Actions workflow-Datei. (z.B.: .github/workflows/pr_benchmarks_closed.yml)

  2. Ausführen bei pull_request-Ereignissen:

    • closed - Ein Pull-Request wurde geschlossen.

    Siehe die GitHub Actions on Dokumentation und die GitHub Actions pull_request Dokumentation für einen vollständigen Überblick. (z.B.: on: pull_request: types: [closed])

  3. Erstellen Sie einen GitHub Actions job. (z.B.: jobs: archive_pr_branch)

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

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

  6. Checken Sie den PR-Branch-Quellcode aus. (z.B.: uses: actions/checkout@v4)

  7. Installieren Sie das Bencher CLI mit dem GitHub Action. (z.B.: uses: bencherdev/bencher@main)

  8. Verwenden Sie den bencher archive CLI-Unterbefehl, um den PR-Branch zu archivieren. (z.B.: bencher archive)

  9. Setzen Sie die --project Option auf den Project-Slug. Siehe die --project Doku für weitere Details. (z.B.: --project save-walter-white-1234abcd)

  10. Setzen Sie die --token Option auf das Repository-Geheimnis BENCHER_API_TOKEN. Siehe die --token Doku für weitere Details. (z.B.: --token '${{ secrets.BENCHER_API_TOKEN }}')

  11. Setzen Sie die --branch Option auf den PR-Branch-Namen unter Verwendung der GitHub Actions GITHUB_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.

.github/workflows/fork_pr_benchmarks_run.yml
name: Run Benchmarks
on:
pull_request:
types: [opened, reopened, edited, synchronize]
jobs:
benchmark_fork_pr_branch:
name: Run Fork PR Benchmarks
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Mock Benchmarking
run: |
/bin/echo '{ "bencher::mock_0": { "latency": { "value": 1.0 } } }' > benchmark_results.json
- name: Upload Benchmark Results
uses: actions/upload-artifact@v4
with:
name: benchmark_results.json
path: ./benchmark_results.json
- name: Upload GitHub Pull Request Event
uses: actions/upload-artifact@v4
with:
name: event.json
path: ${{ github.event_path }}
  1. Erstellen Sie eine erste GitHub Actions workflow-Datei. (z.B.: .github/workflows/fork_pr_benchmarks_run.yml)

  2. Benennen Sie diesen Workflow, sodass er vom zweiten Workflow referenziert werden kann. (z.B.: name: Run Benchmarks)

  3. 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 Actions pull_request-Dokumentation für einen vollständigen Überblick. (z.B.: on: pull_request: types: [opened, reopened, edited, synchronize])

  4. Erstellen Sie einen GitHub Actions job. (z.B.: jobs: benchmark_fork_pr_branch)

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

  6. Überprüfen Sie den Quellcode des Fork PR Branch. (z.B.: uses: actions/checkout@v4)

  7. Führen Sie Ihre Benchmarks durch und speichern Sie die Ergebnisse in einer Datei. (z.B.: /bin/echo '{ ... }' > benchmark_results.json)

  8. Laden Sie die Benchmark-Ergebnisdatei als Artefakt hoch. (z.B.: uses: actions/upload-artifact@v4)

  9. Laden Sie das pull_request-Ereignisobjekt als Artefakt hoch. (z.B.: uses: actions/upload-artifact@v4)

.github/workflows/fork_pr_benchmarks_track.yml
name: Track Benchmarks with Bencher
on:
workflow_run:
workflows: [Run Benchmarks]
types: [completed]
jobs:
track_fork_pr_branch:
if: github.event.workflow_run.conclusion == 'success'
runs-on: ubuntu-latest
env:
BENCHMARK_RESULTS: benchmark_results.json
PR_EVENT: event.json
steps:
- name: Download Benchmark Results
uses: dawidd6/action-download-artifact@v6
with:
name: ${{ env.BENCHMARK_RESULTS }}
run_id: ${{ github.event.workflow_run.id }}
- name: Download PR Event
uses: dawidd6/action-download-artifact@v6
with:
name: ${{ env.PR_EVENT }}
run_id: ${{ github.event.workflow_run.id }}
- name: Export PR Event Data
uses: actions/github-script@v6
with:
script: |
let fs = require('fs');
let prEvent = JSON.parse(fs.readFileSync(process.env.PR_EVENT, {encoding: 'utf8'}));
core.exportVariable("PR_HEAD", prEvent.pull_request.head.ref);
core.exportVariable("PR_BASE", prEvent.pull_request.base.ref);
core.exportVariable("PR_BASE_SHA", prEvent.pull_request.base.sha);
core.exportVariable("PR_NUMBER", prEvent.number);
- uses: bencherdev/bencher@main
- name: Track Benchmarks with Bencher
run: |
bencher run \
--project save-walter-white-1234abcd \
--token '${{ secrets.BENCHER_API_TOKEN }}' \
--branch "$PR_HEAD" \
--start-point "$PR_BASE" \
--start-point-hash "$PR_BASE_SHA" \
--start-point-clone-thresholds \
--start-point-reset \
--testbed ubuntu-latest \
--err \
--adapter json \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
--ci-number "$PR_NUMBER" \
--file "$BENCHMARK_RESULTS"
  1. Erstellen Sie eine erste GitHub Actions workflow Datei. (z. B. .github/workflows/fork_pr_benchmarks_track.yml)
  2. Benennen Sie diesen Workflow als zweiten Workflow. (z. B. name: Track Benchmarks with Bencher)
  3. Verknüpfen Sie die beiden Workflows mit dem workflow_run Ereignis. (z. B. on: workflow_run: ...)
  4. Erstellen Sie einen GitHub Actions job. (z. B. jobs: track_fork_pr_branch)
  5. 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')
  6. 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)
  7. Setzen Sie die Benchmark-Ergebnisse und die Dateinamen des pull_request Ereignisobjekts als Umgebungsvariablen. (z. B. env: ...)
  8. Laden Sie die zwischengespeicherten Benchmark-Ergebnisse und das pull_request Ereignis herunter mit der action-download-artifact GitHub Action. (z. B. uses: dawidd6/action-download-artifact@v6)
  9. Exportieren Sie die notwendigen Daten aus dem pull_request Ereignis als Umgebungsvariablen. (z. B. core.exportVariable(...))
  10. Installieren Sie die Bencher CLI mit der GitHub Action. (z. B. uses: bencherdev/bencher@main)
  11. Verwenden Sie den bencher run CLI-Unterbefehl, um die Benchmarks Ihres Fork-Pull-Zweigs zu verfolgen. Siehe den bencher run CLI-Unterbefehl für einen vollständigen Überblick. (z. B. bencher run)
  12. Setzen Sie die --project Option auf den Projektslug. Siehe die --project Dokumentation für mehr Details. (z. B. --project save-walter-white-1234abcd)
  13. Setzen Sie die --token Option auf das BENCHER_API_TOKEN Repository-Geheimnis. Siehe die --token Dokumentation für mehr Details. (z. B. --token '${{ secrets.BENCHER_API_TOKEN }}')
  14. 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")
  15. Setzen Sie den Ausgangspunkt für den Fork-PR-Zweig:
    1. 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")
    2. Setzen Sie die --start-point-hash Option auf den git-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")
    3. 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)
    4. 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)
  16. Setzen Sie die --testbed Option auf den Testbed-Namen. Dies sollte wahrscheinlich mit der in runs-on ausgewählten Maschine übereinstimmen. Siehe die --tested Dokumentation für mehr Details. (z. B. --testbed ubuntu-latest)
  17. 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)
  18. Setzen Sie die --adapter Option auf Bencher Metric Format JSON (json), das durch bencher mock generiert wird. Siehe die Adapters für Benchmarking-Harnesses für einen vollständigen Überblick. (z. B. --adapter json)
  19. Setzen Sie die --github-actions Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als Kommentar im Pull Request zu posten, unter Verwendung der GitHub Actions GITHUB_TOKEN Umgebungsvariable. Siehe die --github-actions Dokumentation für mehr Details. (z. B. --github-actions '${{ secrets.GITHUB_TOKEN }}')
  20. 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")
  21. 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.

.github/workflows/fork_pr_benchmarks_closed.yml
on:
pull_request_target:
types: [closed]
jobs:
archive_fork_pr_branch:
name: Archive closed fork PR branch with Bencher
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: bencherdev/bencher@main
- name: Archive closed fork PR branch with Bencher
run: |
bencher archive \
--project save-walter-white-1234abcd \
--token '${{ secrets.BENCHER_API_TOKEN }}' \
--branch "$GITHUB_HEAD_REF"
  1. Erstellen Sie eine GitHub Actions workflow-Datei. (z.B.: .github/workflows/fork_pr_benchmarks_closed.yml)

  2. Ausführen bei pull_request_target-Ereignissen:

    • closed - Ein Pull-Request wurde geschlossen.

    Siehe die GitHub Actions on Dokumentation und GitHub Actions pull_request_target Dokumentation für einen vollständigen Überblick. (z.B.: on: pull_request_target: types: [closed])

  3. Erstellen Sie einen GitHub Actions job. (z.B.: jobs: archive_pr_branch)

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

  5. Checken Sie den Quellcode des PR-Branches aus. (z.B.: uses: actions/checkout@v4)

  6. Installieren Sie die Bencher CLI mit der GitHub Action. (z.B.: uses: bencherdev/bencher@main)

  7. Verwenden Sie den bencher archive CLI-Unterbefehl, um den PR-Branch zu archivieren. (z.B.: bencher archive)

  8. Setzen Sie die --project Option auf den Projektslug. Siehe die --project Dokumentation für weitere Details. (z.B.: --project save-walter-white-1234abcd)

  9. Setzen Sie die --token Option auf das Repository-Geheimnis BENCHER_API_TOKEN. Siehe die --token Dokumentation für weitere Details. (z.B.: --token '${{ secrets.BENCHER_API_TOKEN }}')

  10. Setzen Sie die --branch Option auf den PR-Branch-Namen unter Verwendung der GitHub Actions GITHUB_HEAD_REF Standard-Umgebungsvariable. (z.B.: --branch "$GITHUB_HEAD_REF")



🐰 Glückwunsch! Sie haben gelernt, wie man Bencher in GitHub Actions verwendet! 🎉


Weitermachen: Übersicht über Benchmarking ➡

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


Published: Fri, October 27, 2023 at 8:40:00 AM UTC | Last Updated: Mon, November 4, 2024 at 7:40:00 AM UTC