Wie man Bencher in GitHub Actions verwendet


Je nach deinem Anwendungsfall kannst du durchgehende Benchmarks in GitHub Actions für deine:

🐰 Stelle sicher, dass du einen API-Token erstellt hast und setze ihn als Repository-Geheimnis mit dem Namen BENCHER_API_TOKEN, bevor du fortfährst! Navigiere zu Dein Repo -> Einstellungen -> Geheimnisse und Variablen -> Aktionen -> Neues Repository-Geheimnis. Benenne das Geheimnis BENCHER_API_TOKEN und setze den Geheimniswert auf deinen API-Token.

Basisbranch

Eine Grundlage von Statistischem kontinuierlichen Benchmarking ist das Vorhandensein einer historischen Basislinie für Ihren Basisbranch. 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 \
--adapter json \
--err \
bencher mock
  1. Erstellen Sie eine GitHub Actions workflow Datei. (z.B.: .github/workflows/base_benchmarks.yml)
  2. Ausführen bei push Ereignissen auf den main Branch. Siehe die GitHub Actions on Dokumentation und GitHub Actions push Dokumentation für einen vollständigen Überblick. (z.B.: on: push: branches: main)
  3. Erstellen Sie einen GitHub Actions job. (z.B.: jobs: benchmark_base_branch)
  4. Legen Sie den Typ der Maschine fest, auf der 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)
  5. Checken Sie den Quellcode Ihres Basisbranches 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 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)
  8. Legen Sie die --project Option auf den Projektslug fest. Siehe die --project Dokumentation für mehr Details. (z.B.: --project save-walter-white-1234abcd)
  9. Legen Sie die --token Option auf das BENCHER_API_TOKEN Repository Geheimnis fest. Siehe die --token Dokumentation für mehr Details. (z.B.: --token '${{ secrets.BENCHER_API_TOKEN }}')
  10. Legen Sie die --branch Option auf den Namen des Branches fest. Siehe Branchauswahl für einen vollständigen Überblick. (z.B.: --branch main)
  11. Legen Sie die --testbed Option auf den Namen des Testbetts fest. 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)
  12. Legen Sie die --adapter Option auf den gewünschten Benchmark Harness Adapter fest. Siehe Benchmark Harness Adapter für einen vollständigen Überblick. (z.B.: --adapter json)
  13. Legen Sie den --err Schalter fest, um den Befehl bei Auslösung eines Alarms fehlschlagen zu lassen. Siehe Schwellenwert & Alarme für einen vollständigen Überblick. (z.B.: --err)
  14. Geben Sie die Benchmark-Befehlsargumente an. Siehe Benchmarkbefehl für einen vollständigen Überblick. (z.B.: bencher mock)

Pull-Anfragen

Um Leistungsregressionen in Pull-Anfragen zu erfassen, müssen Sie Ihre Benchmarks auf PRs laufen lassen. Wenn Sie nur erwarten, PRs von Branches innerhalb desselben Repositories zu erhalten, dann können Sie einfach einen weiteren Workflow erstellen, um on pull_request Ereignisse vom selben Repository auszuführen.

⚠️ Diese Lösung funktioniert nur, wenn alle PRs vom selben Repository kommen! Siehe Pull-Anfragen 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 }}' \
--branch-start-point '${{ github.base_ref }}' \
--branch-start-point-hash '${{ github.event.pull_request.base.sha }}' \
--testbed ubuntu-latest \
--adapter json \
--err \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
bencher mock
  1. Erstellen Sie eine GitHub Actions workflow-Datei. (Bsp.: .github/workflows/pr_benchmarks.yml)

  2. Ausführen bei pull_request Ereignissen:

    • opened - Eine Pull-Anfrage wurde erstellt.
    • reopened - Eine zuvor geschlossene Pull-Anfrage wurde wieder geöffnet.
    • edited - Der Titel oder Körper einer Pull-Anfrage wurde bearbeitet, oder der Basiszweig einer Pull-Anfrage wurde geändert.
    • synchronize - Der Head-Zweig einer Pull-Anfrage wurde aktualisiert. Zum Beispiel wurde der Head-Zweig vom Basiszweig aktualisiert oder neue Commits wurden zum Head-Zweig gepushed.

    Siehe die GitHub Actions on Dokumentation und GitHub Actions pull_request Dokumentation für einen vollständigen Überblick. (Bsp.: on: pull_request: types: [opened, reopened, edited, synchronize])

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

  4. Führen Sie bei pull_request Ereignissen nur aus, wenn die Pull-Anfrage vom selben Repository stammt. ⚠️ ENTFERNEN SIE DIESE ZEILE NICHT! Für die Bearbeitung von Fork PRs siehe Pull-Anfragen von Forks unten. (Bsp.: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

  5. 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, die nach dem 02. Feb. 2023 erstellt wurden, ist dies das Standardverhalten. Siehe die GitHub-Dokumentation für einen vollständigen Überblick. (Bsp.: permissions: pull-requests: write)

  6. 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. (Bsp.: runs-on: ubuntu-latest)

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

  8. Installieren Sie das Bencher CLI mit der GitHub Action. (Bsp.: uses: bencherdev/bencher@main)

  9. Verwenden Sie den bencher run CLI-Unterbefehl, um die Benchmarks Ihres Pull-Anfrage-Branches zu laufen. Siehe den bencher run CLI-Unterbefehl für einen vollständigen Überblick. (Bsp.: bencher run)

  10. Setzen Sie die --project Option auf den Projekt-Slug. Siehe die --project Docs für weitere Details. (Bsp.: --project save-walter-white-1234abcd)

  11. Setzen Sie die --token Option auf das BENCHER_API_TOKEN Repository Secret. Siehe die --token Docs für weitere Details. (Bsp.: --token '${{ secrets.BENCHER_API_TOKEN }}')

  12. Setzen Sie die --branch-Option auf den Namen des PR-Branches mit dem GitHub Actions github Kontext. Siehe Branch-Auswahl für einen vollständigen Überblick. (Bsp.: --branch '${{ github.head_ref }}')

  13. Setzen Sie die --branch-start-point-Option auf den PR-Basis-Branch-Startpunkt mit dem GitHub Actions github Kontext. Siehe Branch-Auswahl für einen vollständigen Überblick. (Bsp.: --branch-start-point '${{ github.base_ref }}')

  14. Setzen Sie die --branch-start-point-hash-Option auf den PR-Basis-Branch-Startpunkthash mit dem GitHub Actions pull_request Ereignis. Siehe Branch-Auswahl für einen vollständigen Überblick. (Bsp.: --branch-start-point-hash '${{ github.event.pull_request.base.sha }}')

  15. Setzen Sie die --testbed-Option auf den Namen des Testbeds. Dies sollte wahrscheinlich mit der in runs-on ausgewählten Maschine übereinstimmen. Siehe die --tested Docs für weitere Details. (Bsp.: --testbed ubuntu-latest)

  16. Setzen Sie die --adapter-Option auf den gewünschten Benchmark-Harness-Adapter. Siehe Benchmark-Harness-Adapter für einen vollständigen Überblick. (Bsp.: --adapter json)

  17. Setzen Sie das --err-Flag, um den Befehl fehlschlagen zu lassen, wenn ein Alert generiert wird. Siehe Schwellenwerte & Alerts für einen vollständigen Überblick. (Bsp.: --err)

  18. Setzen Sie die --github-actions-Option auf das GitHub API-Authentifizierungstoken, um Ergebnisse als Kommentar auf die Pull-Anfrage zu posten, mit der GitHub Actions GITHUB_TOKEN Umgebungsvariablen. Siehe die --github-actions Docs für weitere Details. (Bsp.: --github-actions '${{ secrets.GITHUB_TOKEN }}')

  19. Geben Sie die Benchmark-Kommandoargumente an. Siehe Benchmark-Kommando für einen vollständigen Überblick. (Bsp.: bencher mock)


Pull Requests von Forks

Wenn Sie planen, Pull Requests von Forks zu akzeptieren, wie es oft bei öffentlichen Open-Source-Projekten der Fall ist, müssen Sie die Dinge etwas anders handhaben. Aus Sicherheitsgründen sind Geheimnisse wie Ihr BENCHER_API_TOKEN und das GITHUB_TOKEN in GitHub Actions für Fork-PRs nicht verfügbar. Das bedeutet, wenn ein externer Beitragender einen PR von einem Fork öffnet, wird das obige Beispiel nicht funktionieren. Es gibt zwei Optionen für Fork-PRs:

Siehe diesen GitHub Security Lab Beitrag und diesen Blog-Post zur Verhinderung von pwn-Anfragen für einen vollständigen Überblick.

Fork PR-Benchmark und Upload vom Standard-Branch

Dies ist die sichere und vorgeschlagene Methode, um kontinuierliches Benchmarking zu Fork-Pull-Requests hinzuzufügen. Dafür werden zwei separate Workflows benötigt. Der erste Workflow führt die Benchmarks aus und speichert die Ergebnisse im pull_request-Kontext. Dort sind keine Geheimnisse wie Ihr BENCHER_API_TOKEN und das GITHUB_TOKEN verfügbar. Dann lädt ein zweiter Workflow die gespeicherten Benchmark-Ergebnisse im workflow_run-Kontext herunter und lädt sie zu Bencher hoch. Das funktioniert, weil workflow_run im Kontext des Standard-Branchs des Repositories ausgeführt wird, wo Geheimnisse wie Ihr BENCHER_API_TOKEN und das GITHUB_TOKEN verfügbar sind. Die Pull-Request-Nummer, der Head-Branch und der Base-Branch, die im initialen pull_request-Workflow verwendet wurden, müssen auch 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 Verwendung von Daten aus dem auslösenden Workflow für einen vollständigen Überblick.

name: Run and Cache 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/run_fork_pr_benchmarks.yml)

  2. Bennen Sie diesen Workflow, damit er vom zweiten Workflow referenziert werden kann. (z. B.: name: Benchmarks ausführen und speichern)

  3. Führen Sie 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 Body eines Pull-Requests wurde bearbeitet, oder der Base-Branch eines Pull-Requests wurde geändert.
    • synchronize - Der Head-Branch eines Pull-Requests wurde aktualisiert. Zum Beispiel wurde der Head-Branch vom Base-Branch aktualisiert oder neue Commits wurden zum Head-Branch gepusht.

    Siehe die GitHub Actions on-Dokumentation und 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. Bestimmen 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)

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

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

  8. Laden Sie die Datei mit den Benchmark-Ergebnissen 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)

name: Track Benchmarks with Bencher
on:
workflow_run:
workflows: [Run and Cache 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: actions/github-script@v6
with:
script: |
async function downloadArtifact(artifactName) {
let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
owner: context.repo.owner,
repo: context.repo.repo,
run_id: context.payload.workflow_run.id,
});
let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
return artifact.name == artifactName
})[0];
if (!matchArtifact) {
core.setFailed(`Failed to find artifact: ${artifactName}`);
}
let download = await github.rest.actions.downloadArtifact({
owner: context.repo.owner,
repo: context.repo.repo,
artifact_id: matchArtifact.id,
archive_format: 'zip',
});
let fs = require('fs');
fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/${artifactName}.zip`, Buffer.from(download.data));
}
await downloadArtifact(process.env.BENCHMARK_RESULTS);
await downloadArtifact(process.env.PR_EVENT);
- name: Unzip Benchmark Results
run: |
unzip $BENCHMARK_RESULTS.zip
unzip $PR_EVENT.zip
- 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 }}' \
--branch-start-point '${{ env.PR_BASE }}' \
--branch-start-point-hash '${{ env.PR_BASE_SHA }}' \
--testbed ubuntu-latest \
--adapter json \
--err \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
--ci-number '${{ env.PR_NUMBER }}' \
--file "$BENCHMARK_RESULTS"
  1. Erstellen Sie eine erste GitHub-Actions workflow-Datei. (z. B.: .github/workflows/track_fork_pr_benchmarks.yml)
  2. Bennen Sie diesen Workflow als zweiten Workflow. (z. B.: name: Benchmarks mit Bencher verfolgen)
  3. Verketten 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 der Schluss des vorherigen Workflows erfolgreich war, mit dem GitHub-Actions workflow_run-Ereignis. (z. B.: if: github.event.workflow_run.conclusion == 'success')
  6. Bestimmen 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)
  7. Setzen Sie die Dateinamen der Benchmark-Ergebnisse und des pull_request-Ereignisobjekts als Umgebungsvariablen. (z. B.: env: ...)
  8. Laden Sie die gespeicherten Benchmark-Ergebnisse und das pull_request-Ereignis herunter. (z. B.: uses: actions/github-script@v6)
  9. Extrahieren Sie die gespeicherten Benchmark-Ergebnisse und das pull_request-Ereignis. (z. B.: unzip ...)
  10. Exportieren Sie die notwendigen Daten aus dem pull_request-Ereignis als Umgebungsvariablen. (z. B.: core.exportVariable(...))
  11. Installieren Sie die Bencher-CLI mit der GitHub-Action. (z. B.: uses: bencherdev/bencher@main)
  12. Verwenden Sie den bencher run-CLI-Subbefehl, um Ihre Fork-Pull-Branch-Benchmarks zu verfolgen. Siehe den bencher run-CLI-Subbefehl für einen vollständigen Überblick. (z. B.: bencher run)
  13. Setzen Sie die --project-Option auf den Projekt-Slug. Siehe die --project-Dokumentation für weitere Details. (z. B.: --project save-walter-white-1234abcd)
  14. Setzen Sie die --token-Option auf das BENCHER_API_TOKEN-Repository-Geheimnis. Siehe die --token-Dokumentation für weitere Details. (z. B.: --token '${{ secrets.BENCHER_API_TOKEN }}')
  15. Setzen Sie die --branch-Option auf die formatierte Fork-PR-Nummer mit dem GitHub-Actions pull_request-Ereignis. Siehe Branch-Auswahl für einen vollständigen Überblick. (z. B.: --branch '${{ env.PR_HEAD }}')
  16. Setzen Sie die --branch-start-point-Option auf den Startpunkt des Fork-PR-Base-Branches mit dem GitHub-Actions pull_request-Ereignis. Siehe Branch-Auswahl für einen vollständigen Überblick. (z. B.: --branch-start-point '${{ env.PR_BASE }}')
  17. Setzen Sie die --branch-start-point-hash-Option auf den Hash des Startpunkts des Fork-PR-Base-Branches mit dem GitHub-Actions pull_request-Ereignis. Siehe Branch-Auswahl für einen vollständigen Überblick. (z. B.: --branch-start-point-hash '${{ env.PR_BASE_SHA }}')
  18. Setzen Sie die --testbed-Option auf den Namen des Testbetts. Dies sollte wahrscheinlich der in runs-on ausgewählten Maschine entsprechen. Siehe die --testbed-Dokumentation für weitere Details. (z. B.: --testbed ubuntu-latest)
  19. Setzen Sie die --adapter-Option auf den gewünschten Benchmark-Harness-Adapter. Siehe Benchmark-Harness-Adapter für einen vollständigen Überblick. (z. B.: --adapter json)
  20. Setzen Sie das --err-Flag, um den Befehl fehlschlagen zu lassen, wenn ein Alert erzeugt wird. Siehe Schwellenwerte & Alerts für einen vollständigen Überblick. (z. B.: --err)
  21. Setzen Sie die --github-actions-Option auf das GitHub-API-Authentifizierungstoken, um Ergebnisse als Kommentar im Pull-Request zu posten mit der GitHub-Actions GITHUB_TOKEN-Umgebungsvariablen. Siehe die --github-actions-Dokumentation für weitere Details. (z. B.: --github-actions '${{ secrets.GITHUB_TOKEN }}')
  22. Setzen Sie die --ci-number-Option auf die Pull-Request-Nummer. Siehe die --ci-number-Dokumentation für weitere Details. (z. B.: --ci-number '${{ env.PR_NUMBER }}')
  23. 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")

Benchmark von Fork-PRs im Vergleich zum Zielbranch mit erforderlichen Gutachtern

Um zu garantieren, dass der Code aus einem Fork-Pull-Request sicher ist, prüft diese GitHub Action, ob der Fork aus einem anderen Repository stammt. Wenn der Fork aus einem anderen Repository kommt, dann muss er überprüft werden.

⚠️ Es ist sehr, sehr wichtig, jeden Fork-PR gründlich zu überprüfen, bevor er genehmigt wird! Andernfalls könnte das Ergebnis ein Pwn-Request sein!

Wenn Sie das nicht über Ihrem Kopf hängen haben möchten, sehen Sie sich [Benchmark von Fork-PR und Upload vom Standardbranch][benchmark fork pr and upload from default branch] oben an.

Um diesen Workflow zu konfigurieren, müssen Sie zwei GitHub Actions-Umgebungen erstellen. Navigieren Sie zu Ihr Repository -> Einstellungen -> Umgebungen -> Neue Umgebung. Erstellen Sie zwei neue Umgebungen, internal und external. Die internal Umgebung sollte keine Deployment-Schutzregeln haben. Die external Umgebung sollte jedoch Erforderliche Gutachter festlegen, die vertrauenswürdig sind, um Fork-PRs zu überprüfen, bevor sie benchmarkt werden. Siehe diesen Blog-Post für eine vollständige Übersicht.

Diese Einrichtung funktioniert, weil pull_request_target im Kontext des Zielbranchs des Pull-Requests ausgeführt wird, wo Geheimnisse wie Ihr BENCHER_API_TOKEN und das GITHUB_TOKEN verfügbar sind. Daher wird dieser Workflow nur ausgeführt, wenn er im Zielbranch vorhanden ist. Setzen Sie keine Geheimnisse als Umgebungsvariablen, wie GITHUB_TOKEN und BENCHER_API_TOKEN. Geben Sie stattdessen Ihre Geheimnisse explizit an bencher run weiter.

on:
pull_request_target:
types: [opened, reopened, edited, synchronize]
jobs:
fork_pr_requires_review:
environment: ${{ (github.event.pull_request.head.repo.full_name == github.repository && 'internal') || 'external' }}
runs-on: ubuntu-latest
steps:
- run: true
benchmark_fork_pr_branch:
needs: fork_pr_requires_review
name: Continuous Benchmarking Fork PRs with Bencher
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.event.pull_request.head.sha }}
persist-credentials: false
- uses: bencherdev/bencher@main
- name: Track Fork PR Benchmarks with Bencher
run: |
bencher run \
--project save-walter-white-1234abcd \
--token '${{ secrets.BENCHER_API_TOKEN }}' \
--branch '${{ github.event.number }}/merge' \
--branch-start-point '${{ github.base_ref }}' \
--branch-start-point-hash '${{ github.event.pull_request.base.sha }}' \
--testbed ubuntu-latest \
--adapter json \
--err \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
bencher mock
  1. Erstellen Sie eine GitHub Actions workflow-Datei. (z.B.: .github/workflows/pr_target_benchmarks.yml)

  2. Ausführen bei pull_request-Ereignissen:

    • opened - Ein Pull-Request wurde erstellt.
    • reopened - Ein zuvor geschlossener Pull-Request wurde wieder geöffnet.
    • edited - Der Titel oder Körper eines Pull-Requests wurde bearbeitet oder der Basisbranch eines Pull-Requests wurde geändert.
    • synchronize - Der Head-Branch eines Pull-Requests wurde aktualisiert. Beispielsweise wurde der Head-Branch vom Basisbranch aktualisiert oder neue Commits wurden zum Head-Branch gepusht.

    Siehe die GitHub Actions on Dokumentation und GitHub Actions pull_request Dokumentation für eine vollständige Übersicht. (z.B.: on: pull_request: types: [opened, reopened, edited, synchronize])

  3. Erstellen Sie einen ersten GitHub Actions job, um zu prüfen, ob der Workflow eine Überprüfung erfordert. (z.B.: jobs: fork_pr_requires_review)

  4. Setzen Sie die Umgebung auf internal, wenn und nur wenn der Pull-Request aus demselben Repository stammt. Andernfalls setzen Sie die Umgebung auf external, was eine Genehmigung eines Gutachters erfordert, um fortzufahren. ⚠️ ENTFERNEN SIE DIESE ZEILE NICHT! (z.B.: environment: ${{ (github.event.pull_request.head.repo.full_name == github.repository && 'internal') || 'external' }})

  5. Erstellen Sie einen zweiten GitHub Actions job, um Ihre Benchmarks auszuführen. (z.B.: benchmark_fork_pr_branch)

  6. Der benchmark_fork_pr_branch job muss den fork_pr_requires_review job benötigen, um ausgeführt zu werden. ⚠️ ENTFERNEN SIE DIESE ZEILE NICHT! Siehe die GitHub Actions needs Dokumentation für eine vollständige Übersicht. (z.B.: needs: fork_pr_requires_review)

  7. Legen Sie den Typ der Maschine fest, auf der der Job ausgeführt wird. Siehe die GitHub Actions runs-on Dokumentation für eine vollständige Übersicht. (z.B.: runs-on: ubuntu-latest)

  8. Checken Sie den Quellcode des Fork-PR aus. Da pull_request_target im Kontext des Zielbranchs des Pull-Requests ausgeführt wird, müssen Sie dennoch den Pull-Request-Branch auschecken. (z.B.: uses: actions/checkout@v4)

    • Geben Sie das Fork-PR-Repository an (z.B.: repository: ${{ github.event.pull_request.head.repo.full_name }})
    • Geben Sie den Fork-PR-Hash an (z.B.: ref: ${{ github.event.pull_request.head.sha }})
    • Bewahren Sie Ihre git-Anmeldedaten nicht auf (z.B.: persist-credentials: false)
  9. Installieren Sie die Bencher CLI mit der GitHub Action. (z.B.: uses: bencherdev/bencher@main)

  10. Verwenden Sie den Befehl bencher run um Ihre Benchmarks des Fork-Pull-Branchs auszuführen. Siehe den bencher run Befehl für eine vollständige Übersicht. (z.B.: bencher run)

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

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

  13. Legen Sie die --branch Option auf die formatierte Fork-PR-Nummer fest, indem Sie das GitHub Actions pull_request Ereignis verwenden. Siehe Branch-Auswahl für eine vollständige Übersicht. (z.B.: --branch '${{ github.event.number }}/merge')

  14. Setzen Sie die --branch-start-point Option auf den Basisbranch-Startpunkt des Fork-PR, indem Sie den GitHub Actions github Kontext verwenden. Siehe Branch-Auswahl für eine vollständige Übersicht. (z.B.: --branch-start-point '${{ github.base_ref }}')

  15. Setzen Sie die --branch-start-point-hash Option auf den Basisbranch-Startpunkt-Hash des Fork-PR, indem Sie das GitHub Actions pull_request Ereignis verwenden. Siehe Branch-Auswahl für eine vollständige Übersicht. (z.B.: --branch-start-point-hash '${{ github.event.pull_request.base.sha }}')

  16. Setzen Sie die --testbed Option auf den Namen des Testbetts. Dies sollte wahrscheinlich der in runs-on ausgewählten Maschine entsprechen. Siehe die --testbed Dokumentation für weitere Details. (z.B.: --testbed ubuntu-latest)

  17. Setzen Sie die --adapter Option auf den gewünschten Benchmark-Harness-Adapter. Siehe Benchmark-Harness-Adapter für eine vollständige Übersicht. (z.B.: --adapter json)

  18. Setzen Sie das --err Flag, um den Befehl fehlschlagen zu lassen, wenn ein Alert generiert wird. Siehe Schwellenwerte & Alerts für eine vollständige Übersicht. (z.B.: --err)

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

  20. Geben Sie die Benchmark-Befehlsargumente an. Siehe Benchmark-Befehl für eine vollständige Übersicht. (z.B.: bencher mock)



🐰 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, April 1, 2024 at 7:00:00 AM UTC