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

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.

on:
  push:
    branches: main

jobs:
  benchmark_base_branch:
    name: Continuous Benchmarking with Bencher
    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

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)
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 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 save-walter-white-1234abcd)
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 }}')
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 --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 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 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.

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

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 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)
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 auf write für pull-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 das bencher 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 das BENCHER_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 Actions github 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:
1. Setzen Sie die --start-point-Option auf den Startpunkt des PR-Branches mithilfe des GitHub Actions github Kontexts. 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 Startpunkts des PR-Branches mithilfe des GitHub Actions pull_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 }}')
3. 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)
4. 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 --testbed-Option auf den Testbed-Namen. Dies sollte wahrscheinlich mit der in runs-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 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 Kommentar im Pull-Request zu posten, mithilfe der GitHub Actions GITHUB_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.

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
    permissions:
      pull-requests: write
    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 }}'

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 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ü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)
Setzen Sie die Berechtigungen für das GITHUB_TOKEN auf write für pull-requests. Abhängig von Ihren GitHub-Einstellungen ist dies möglicherweise nicht erforderlich. Doch bei allen Organisationen und persönlichen Repositories, die nach dem 02. Feb 2023 erstellt wurden, ist dies das Standardverhalten. Lesen Sie 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. 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-Geheimnis BENCHER_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 Actions github 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.

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

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

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.number}/merge`);
            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 '${{ env.PR_HEAD }}' \
          --start-point '${{ env.PR_BASE }}' \
          --start-point-hash '${{ env.PR_BASE_SHA }}' \
          --start-point-clone-thresholds \
          --start-point-reset \
          --testbed ubuntu-latest \
          --err \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          --ci-number '${{ env.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 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 der action-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 den bencher 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 das BENCHER_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 Actions github 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:
1. Setzen Sie die --start-point Option auf den Startpunkt des Fork PR Branch mithilfe [des GitHub Actions github Kontext][github actions context]. Siehe die --start-point Dokumentation für einen vollständigen Überblick. (z.B.: --start-point '${{ env.PR_BASE }}')
2. Setzen Sie die --start-point-hash Option auf den Startpunkt-Git-Hash des Fork PR Branch mithilfe des GitHub Actions pull_request Ereignis. Siehe die --start-point-hash Dokumentation für einen vollständigen Überblick. (z.B.: --start-point-hash '${{ env.PR_BASE_SHA }}')
3. 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)
4. 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 --testbed Option auf den Testbed-Namen. Dies sollte wahrscheinlich mit der in runs-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 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-Authentifizierungs-Token, um die Ergebnisse als Kommentar in der Pull-Anfrage zu posten, mithilfe 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-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.

on:
  pull_request:
    types: [closed]

jobs:
  archive_fork_pr_branch:
    name: Archive closed fork PR branch with Bencher
    permissions:
      pull-requests: write
    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 }}'

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 Actions pull_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)
Setzen Sie die Berechtigungen für das GITHUB_TOKEN auf write für pull-requests. Abhängig von Ihren GitHub-Einstellungen ist dies möglicherweise nicht erforderlich. Aber für alle Organisationen und persönlichen Repos erstellt nach dem 02. Februar 2023, ist dies das Standardverhalten. Siehe 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 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-Geheimnis BENCHER_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 Actions github Kontexts. (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: Sat, October 12, 2024 at 12:40:00 PM UTC