Wie man Bencher in GitHub Actions verwendet

Je nach Anwendungsfall können Sie Continuous Benchmarking in GitHub Actions für Ihre:

Hauptzweig
Pull Requests
Pull Requests aus Forks
Pull Requests auf dedizierter Hardware

Stellen Sie sicher, dass Sie einen Projekt-API-Schlüssel erstellt haben und ihn als Repository-Geheimnis mit dem Namen BENCHER_API_KEY festgelegt haben, bevor Sie fortfahren! Navigieren Sie zu Ihr Repo -> Einstellungen -> Geheimnisse und Variablen -> Aktionen -> Neues Repository-Geheimnis. Benennen Sie das Geheimnis BENCHER_API_KEY und setzen Sie den Geheimniswert auf Ihren Projekt-API-Schlüssel.

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_KEY-Geheimnis nicht verfügbar sein. ${{ secrets.BENCHER_API_KEY }} 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.

on:
  push:
    branches: main

jobs:
  benchmark_base_branch:
    name: Continuous Benchmarking with Bencher
    permissions:
      checks: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: bencherdev/bencher@main
      - name: Track base branch benchmarks with Bencher
        run: |
          bencher run \
          --project project-abc4567-wxyz123456789 \
          --key '${{ secrets.BENCHER_API_KEY }}' \
          --branch main \
          --testbed ubuntu-latest \
          --threshold-measure latency \
          --threshold-test t_test \
          --threshold-max-sample-size 64 \
          --threshold-upper-boundary 0.99 \
          --thresholds-reset \
          --error-on-alert \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          bencher mock

Erstellen Sie eine workflow-Datei für GitHub Actions. (z.B.: .github/workflows/base_benchmarks.yml)
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)
Erstellen Sie einen job für GitHub Actions. (z.B.: jobs: benchmark_base_branch)
Setzen Sie die Berechtigungen für das GITHUB_TOKEN auf write für checks. (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@v6)
Installieren Sie die Bencher CLI mithilfe der GitHub Action. (z.B.: uses: bencherdev/bencher@main)
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)
Setzen Sie die --project Option auf den Project-Slug. Siehe die --project Doku für weitere Details. (z.B.: --project project-abc4567-wxyz123456789)
Setzen Sie die --key Option auf das Repository-Geheimnis BENCHER_API_KEY. Siehe die --key Doku für weitere Details. (z.B.: --key '${{ secrets.BENCHER_API_KEY }}')
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 in runs-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 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)
Setzen Sie die --error-on-alert Flag, damit der Befehl fehlschlägt, wenn ein Alert generiert wird. Siehe die --error-on-alert Doku für einen vollständigen Überblick. (z.B.: --error-on-alert)
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)
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 }}')
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.

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:
      checks: write
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: bencherdev/bencher@main
      - name: Track PR Benchmarks with Bencher
        run: |
          bencher run \
          --project project-abc4567-wxyz123456789 \
          --key '${{ secrets.BENCHER_API_KEY }}' \
          --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 \
          --error-on-alert \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          bencher mock

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 Actions pull_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 auf write für checks und 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: checks: write 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@v6)
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 den bencher 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 project-abc4567-wxyz123456789)
Setzen Sie die --key-Option auf das Repository-Geheimnis BENCHER_API_KEY. Siehe die --key Dokumentation für weitere Details. (z.B.: --key '${{ secrets.BENCHER_API_KEY }}')
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")
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)
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)
Setzen Sie das --error-on-alert Flag, um den Befehl zu beenden, wenn ein Alarm generiert wird. Siehe die --error-on-alert Dokumentation für einen vollständigen Überblick. (z.B.: --error-on-alert)
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)
Setzen Sie die --github-actions-Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als GitHub-Prüfung und 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 }}')
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.

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@v6
      - uses: bencherdev/bencher@main
      - name: Archive closed PR branch with Bencher
        run: |
          bencher archive \
          --project project-abc4567-wxyz123456789 \
          --key '${{ secrets.BENCHER_API_KEY }}' \
          --branch "$GITHUB_HEAD_REF"

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 Actions pull_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@v6)
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 project-abc4567-wxyz123456789)
Setzen Sie die --key Option auf das Repository-Geheimnis BENCHER_API_KEY. Siehe die --key Doku für weitere Details. (z.B.: --key '${{ secrets.BENCHER_API_KEY }}')
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_KEY 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_KEY 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_KEY 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.

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@v6
      - 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 }}

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 Actions pull_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@v6)
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)

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'
    permissions:
      checks: write
      pull-requests: write
    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_HEAD_SHA", prEvent.pull_request.head.sha);
            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 project-abc4567-wxyz123456789 \
          --key '${{ secrets.BENCHER_API_KEY }}' \
          --branch "$PR_HEAD" \
          --hash "$PR_HEAD_SHA" \
          --start-point "$PR_BASE" \
          --start-point-hash "$PR_BASE_SHA" \
          --start-point-clone-thresholds \
          --start-point-reset \
          --testbed ubuntu-latest \
          --error-on-alert \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          --ci-number "$PR_NUMBER" \
          --file "$BENCHMARK_RESULTS"

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)
Verketten Sie die beiden Workflows mit dem workflow_run Event. (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 der Abschluss des vorherigen Workflows erfolgreich war, unter Verwendung des GitHub Actions workflow_run Events. (z.B.: if: github.event.workflow_run.conclusion == 'success')
Setzen Sie die Berechtigungen für den GITHUB_TOKEN auf write für checks und pull-requests. Abhängig von Ihren GitHub-Einstellungen ist dies möglicherweise nicht erforderlich. Aber für alle Organisationen und persönlichen Repositories die nach dem 02. Feb 2023 erstellt wurden, ist dies das Standardverhalten. Siehe die GitHub-Dokumentation für einen vollständigen Überblick. (z.B.: permissions: checks: write pull-requests: write)
Setzen Sie den Typ der Maschine, 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 Event-Objekts als Umgebungsvariablen. (z.B.: env: ...)
Laden Sie die zwischengespeicherten Benchmark-Ergebnisse und das pull_request Event herunter unter Verwendung der GitHub Action action-download-artifact. (z.B.: uses: dawidd6/action-download-artifact@v6)
Exportieren Sie die notwendigen Daten vom pull_request Event als Zwischen-Umgebungsvariablen. (z.B.: core.exportVariable(...))
Installieren Sie das Bencher CLI unter Verwendung der GitHub Action. (z.B.: uses: bencherdev/bencher@main)
Verwenden Sie den bencher run CLI-Unterbefehl, um die Benchmarks Ihrer Fork-Pull-Branch zu verfolgen. Siehe den bencher run CLI-Unterbefehl für einen vollständigen Überblick. (z.B.: bencher run)
Setzen Sie die --project Option auf den Projektschlüssel. Siehe die --project Dokumentation für weitere Details. (z.B.: --project project-abc4567-wxyz123456789)
Setzen Sie die --key Option auf das Repository-Geheimnis BENCHER_API_KEY. Siehe die --key Dokumentation für weitere Details. (z.B.: --key '${{ secrets.BENCHER_API_KEY }}')
Setzen Sie die --branch Option auf den Namen des Fork-PR-Branches unter Verwendung einer Zwischen-Umgebungsvariable. Siehe die --branch Dokumentation für einen vollständigen Überblick. (z.B.: --branch "$PR_HEAD")
Setzen Sie die --hash Option auf den git-Hash des Fork-PR-Branches unter Verwendung einer Zwischen-Umgebungsvariable. Siehe die --hash Dokumentation für einen vollständigen Überblick. (z.B.: --hash "$PR_HEAD_SHA")
Setzen Sie den Startpunkt für den Fork-PR-Branch:
1. Setzen Sie die --start-point Option auf den Startpunkt des Fork-PR-Branches unter Verwendung einer Zwischen-Umgebungsvariable. 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 Startpunktes vom Fork-PR-Branch unter Verwendung einer Zwischen-Umgebungsvariable. Siehe die --start-point-hash Dokumentation für einen vollständigen Überblick. (z.B.: --start-point-hash "$PR_BASE_SHA")
3. Setzen Sie die --start-point-clone-thresholds Flagge, 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)
4. Setzen Sie die --start-point-reset Flagge, um den Fork-PR-Branch immer zum Startpunkt zurückzusetzen. Dies verhindert ein Drift der Benchmark-Daten. Siehe die --start-point-reset Dokumentation für einen vollständigen Überblick. (z.B.: --start-point-reset)
Setzen Sie die --testbed Option auf den Namen des Testbed. Dies sollte vermutlich mit der in runs-on ausgewählten Maschine übereinstimmen. Siehe die --tested Dokumentation für weitere Details. (z.B.: --testbed ubuntu-latest)
Setzen Sie die --error-on-alert Flagge, um den Befehl fehlschlagen zu lassen, wenn ein Alarm erzeugt wird. Siehe die --error-on-alert Dokumentation für einen vollständigen Überblick. (z.B.: --error-on-alert)
Setzen Sie die --adapter Option auf Bencher Metric Format JSON (json), das von bencher mock erzeugt 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 GitHub-Prüfung und als Kommentar im Pull Request zu posten, unter Verwendung der GITHUB_TOKEN Umgebungsvariable der GitHub Actions. Siehe die --github-actions Dokumentation für weitere Details. (z.B.: --github-actions '${{ secrets.GITHUB_TOKEN }}')
Setzen Sie die --ci-number Option auf die Nummer des Pull Requests unter Verwendung einer Zwischen-Umgebungsvariable. Siehe die --ci-number Dokumentation für weitere 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.

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@v6
      - uses: bencherdev/bencher@main
      - name: Archive closed fork PR branch with Bencher
        run: |
          bencher archive \
          --project project-abc4567-wxyz123456789 \
          --key '${{ secrets.BENCHER_API_KEY }}' \
          --branch "$GITHUB_HEAD_REF"

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 Actions pull_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@v6)
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 project-abc4567-wxyz123456789)
Setzen Sie die --key Option auf das Repository-Geheimnis BENCHER_API_KEY. Siehe die --key Dokumentation für weitere Details. (z.B.: --key '${{ secrets.BENCHER_API_KEY }}')
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")

Pull Requests auf dedizierter Hardware

GitHub Actions bietet selbstgehostete Runner, doch dafür müssen Sie deren verrauschtes GitHub Actions Runner-Binary verwenden. Bencher Bare Metal führt Benchmarks auf einer dedizierten Flotte von Bare-Metal-Hardware mit einem eigens dafür entwickelten, rauscharmen Benchmark-Runner aus. Außerdem unterstützt Bencher Bare Metal PRs aus Forks, während der GitHub Actions Runner das nicht tut.

Sobald Sie auf Bencher Bare Metal umgestiegen sind, möchten Sie keinen GitHub Actions Job laufen lassen, während er auf Bencher wartet. Um das zu lösen, verwendet Bencher einen aufgeteilten Workflow, damit GitHub Actions asynchron auf Jobs von Bencher Bare Metal warten kann.

Das folgende Beispiel ist für Branches innerhalb desselben Repositorys gedacht. Kombinieren Sie dieses Muster mit dem obigen Workflow Pull Requests aus Forks, um Benchmarking auf dedizierter Hardware für Fork-PRs zu erhalten.

on:
  pull_request:
    types: [opened, reopened, edited, synchronize]

jobs:
  submit_pr_benchmarks:
    name: Submit PR Benchmarks to Bencher Bare Metal
    # 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:
      checks: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: bencherdev/bencher@main
      - name: Submit PR Benchmarks with Bencher
        run: |
          bencher run \
          --project project-abc4567-wxyz123456789 \
          --key '${{ secrets.BENCHER_API_KEY }}' \
          --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 \
          --adapter json \
          --image project-abc4567-wxyz123456789:latest \
          --detach \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          --ci-callback-token '${{ secrets.BENCHER_CALLBACK_TOKEN }}' \
          bencher mock

Erstellen Sie eine erste GitHub Actions workflow-Datei. (z.B.: .github/workflows/pr_bare_metal_benchmarks.yml)
Ausführung bei pull_request-Ereignissen, wie oben unter Pull Requests. (z.B.: on: pull_request: types: [opened, reopened, edited, synchronize])
Erstellen Sie einen GitHub Actions job. (z.B.: jobs: submit_pr_benchmarks)
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 oben 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 auf write für checks fest. Der erste Workflow startet die GitHub-Prüfung und veröffentlicht keinen Kommentar. (z.B.: permissions: checks: write)
Legen Sie die Art der Maschine fest, auf der der Job läuft. Er reicht nur den Job ein, daher genügt eine kleine Maschine. (z.B.: runs-on: ubuntu-latest)
Checken Sie den Quellcode des PR-Branches aus. (z.B.: uses: actions/checkout@v6)
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 einzureichen. Siehe den bencher 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 project-abc4567-wxyz123456789)
Setzen Sie die --key-Option auf das Repository-Geheimnis BENCHER_API_KEY. Siehe die --key Dokumentation für weitere Details. (z.B.: --key '${{ secrets.BENCHER_API_KEY }}')
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")
Setzen Sie den Startpunkt für den PR-Branch, wie oben unter Pull Requests. Siehe die --start-point Dokumentation für einen vollständigen Überblick. (z.B.: --start-point "$GITHUB_BASE_REF")
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)
Setzen Sie die --image-Option auf Ihr Image für dedizierte Hardware. Siehe die --image Dokumentation für einen vollständigen Überblick. (z.B.: --image project-abc4567-wxyz123456789:latest)
Setzen Sie das --detach Flag, um sich zu beenden, sobald der Job eingereicht ist. Siehe die --detach Dokumentation für weitere Details. (z.B.: --detach)
Setzen Sie die --github-actions-Option auf das GitHub API-Authentifizierungstoken, um die GitHub-Prüfung zu starten, unter Verwendung der GitHub Actions GITHUB_TOKEN Umgebungsvariable. Siehe die --github-actions Dokumentation für mehr Details. (z.B.: --github-actions '${{ secrets.GITHUB_TOKEN }}')
Setzen Sie die --ci-callback-token-Option auf das Repository-Geheimnis BENCHER_CALLBACK_TOKEN, damit Bencher das repository_dispatch-Ereignis senden kann, wenn der Job beendet ist. Siehe die --ci-callback-token Dokumentation für weitere Details. (z.B.: --ci-callback-token '${{ secrets.BENCHER_CALLBACK_TOKEN }}')
Geben Sie den Benchmark-Befehl an, der im Image ausgeführt wird. Der Befehl wird an den Entrypoint des Images übergeben, falls es einen hat (siehe die Option --entrypoint). Siehe Benchmark Befehl für einen vollständigen Überblick. (z.B.: bencher mock)

on:
  repository_dispatch:
    types: [bencher_run]

jobs:
  attach_pr_benchmarks:
    name: Post PR Benchmark Results from Bencher Bare Metal
    permissions:
      checks: write
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - uses: bencherdev/bencher@main
      - name: Post PR Benchmark Results with Bencher
        env:
          JOB_UUID: ${{ github.event.client_payload.bencher.job }}
        run: |
          bencher run \
          --project project-abc4567-wxyz123456789 \
          --key '${{ secrets.BENCHER_API_KEY }}' \
          --job "$JOB_UUID" \
          --error-on-alert \
          --github-actions '${{ secrets.GITHUB_TOKEN }}'

Erstellen Sie eine zweite GitHub Actions workflow-Datei auf Ihrem Standard-Branch. GitHub führt einen repository_dispatch-Workflow nur vom Standard-Branch aus, daher bleibt die GitHub-Prüfung, die der erste Workflow startet, so lange in Bearbeitung, bis diese Datei dort liegt. (z.B.: .github/workflows/pr_bare_metal_benchmarks_attach.yml)
Ausführung bei repository_dispatch-Ereignissen vom Typ bencher_run. Siehe die GitHub Actions on Dokumentation und die GitHub Actions repository_dispatch Dokumentation für einen vollständigen Überblick. (z.B.: on: repository_dispatch: types: [bencher_run])
Erstellen Sie einen GitHub Actions job. (z.B.: jobs: attach_pr_benchmarks)
Legen Sie die Berechtigungen für das GITHUB_TOKEN auf write für checks und pull-requests fest. (z.B.: permissions: checks: write pull-requests: write)
Legen Sie die Art der Maschine fest, auf der der Job läuft. Der Job ist bereits beendet, daher veröffentlicht dieser Job nur die Ergebnisse. (z.B.: runs-on: ubuntu-latest)
Installieren Sie die Bencher CLI mithilfe der GitHub Action. Ein Checkout ist nicht nötig. (z.B.: uses: bencherdev/bencher@main)
Übergeben Sie die Job-UUID aus dem Ereignis über eine Zwischen-Umgebungsvariable, niemals direkt in run:, wie es GitHubs Hinweise zu Script-Injection verlangen. (z.B.: env: JOB_UUID: ${{ github.event.client_payload.bencher.job }})
Verwenden Sie den bencher run CLI-Unterbefehl, um sich mit dem Job zu verbinden. Siehe den bencher run CLI-Unterbefehl für einen vollständigen Überblick. (z.B.: bencher run)
Setzen Sie die --project-Option auf das Projekt-Slug. Wenn das Repository mehr als ein Projekt hat, übergeben Sie github.event.client_payload.bencher.project auf dieselbe Weise über eine Umgebungsvariable und setzen Sie sie in Anführungszeichen (z.B.: --project "$PROJECT_SLUG"). Siehe die --project Dokumentation für weitere Details. (z.B.: --project project-abc4567-wxyz123456789)
Setzen Sie die --key-Option auf das Repository-Geheimnis BENCHER_API_KEY. Siehe die --key Dokumentation für weitere Details. (z.B.: --key '${{ secrets.BENCHER_API_KEY }}')
Setzen Sie die --job-Option auf die Job-UUID in Anführungszeichen. Siehe die --job Dokumentation für einen vollständigen Überblick. (z.B.: --job "$JOB_UUID")
Setzen Sie das --error-on-alert Flag, um den Befehl zu beenden, wenn ein Alarm generiert wird. Das Ereignis trägt nur Daten, daher gehören Optionen, die festlegen, wie die Ergebnisse veröffentlicht werden, wie --ci-only-on-alert und --ci-public-links, ebenfalls hierher, in den zweiten Workflow. Siehe die --error-on-alert Dokumentation für einen vollständigen Überblick. (z.B.: --error-on-alert)
Setzen Sie die --github-actions-Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als GitHub-Prüfung und als Kommentar im Pull Request zu posten, unter Verwendung der GitHub Actions GITHUB_TOKEN Umgebungsvariable. Eine explizite --ci-number oder --ci-id an dieser Stelle hat Vorrang vor dem Ereignis. Siehe die --github-actions Dokumentation für mehr Details. (z.B.: --github-actions '${{ secrets.GITHUB_TOKEN }}')

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

Weitermachen: Übersicht über Benchmarking ➡

🤖 Dieses Dokument wurde automatisch von KI übersetzt. 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: Sun, September 27, 2026 at 12:00:00 AM UTC