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.

In GitHub Actions, Geheimnisse werden dem Runner nicht ├╝bergeben, wenn ein Workflow von einem geforkten Repository ausgel├Âst wird. Daher m├╝ssen Sie einen Branch aus demselben Repository verwenden, wenn Sie einen der unten stehenden Workflows mit einer Pull-Anfrage zu Ihrem Repository hinzuf├╝gen. Wenn Sie versuchen, Bencher mit einer Pull-Anfrage von einem Fork hinzuzuf├╝gen, wird das BENCHER_API_TOKEN Geheimnis nicht verf├╝gbar sein. ${{ secrets.BENCHER_API_TOKEN }} wird eine leere Zeichenkette sein.

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, June 10, 2024 at 7:17:00 PM UTC