Как использовать Bencher в GitHub Actions

Depending on your use case, you can set up Continuous Benchmarking in GitHub Actions for your:

Make sure you have created a project API key and set it as a Repository secret named BENCHER_API_KEY before continuing on! Navigate to Your Repo -> Settings -> Secrets and variables -> Actions -> New repository secret. Name the secret BENCHER_API_KEY and set the secret value to your project API key.

In GitHub Actions, secrets are not passed to the runner when a workflow is triggered from a forked repository. Therefore, you will need to use a branch from the same repository when adding any of the workflows below to your repository with a pull request. If you try to add Bencher with a pull request from a fork, then the BENCHER_API_KEY secret will not be available. ${{ secrets.BENCHER_API_KEY }} will be an empty string.

Основная ветка

Краеугольным камнем Статистического непрерывного бенчмаркинга является наличие исторического базового уровня для вашей основной ветки. Этот исторический базовый уровень затем может быть использован для обнаружения ухудшений производительности в Pull Requests.

.github/workflows/base_benchmarks.yml
on:
  push:
    branches: main


jobs:
  benchmark_base_branch:
    name: Continuous Benchmarking with Bencher
    permissions:
      checks: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@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
  1. Создайте файл workflow для GitHub Actions. (например, .github/workflows/base_benchmarks.yml)
  2. Запустите при событиях push в ветку main. См. документацию GitHub Actions on и документацию о push для GitHub Actions для получения общей информации. (например, on: push: branches: main)
  3. Создайте job для GitHub Actions. (например, jobs: benchmark_base_branch)
  4. Установите разрешения для GITHUB_TOKEN на write для checks. (например: permissions: checks: write)
  5. Установите тип машины, на которой будет выполняться задание. См. документацию о runs-on для GitHub Actions для получения подробной информации. (например, runs-on: ubuntu-latest)
  6. Получите исходный код вашей основной ветки. (например, uses: actions/checkout@v6)
  7. Установите Bencher CLI, используя GitHub Action. (например, uses: bencherdev/bencher@main)
  8. Используйте подкaманды CLI bencher run для запуска бенчмарков вашей ветки main. См. подкaманды CLI bencher run для получения полной информации. (например, bencher run)
  9. Установите опцию --project на шифр проекта. См. документацию о --project для получения более подробной информации. (например, --project project-abc4567-wxyz123456789)
  10. Установите опцию --key на секрет Repositorий BENCHER_API_KEY. См. документацию о --key для получения более подробной информации. (например, --key '${{ secrets.BENCHER_API_KEY }}')
  11. Установите опцию --branch на имя основной ветки. См. документацию о --branch для получения полной информации. (например, --branch main)
  12. Установите опцию --testbed на имя Testbed. Это, вероятно, должно соответствовать машине, выбранной в runs-on. См. документацию о --tested для получения более подробной информации. (например, --testbed ubuntu-latest)
  13. Установите порог для ветки main, тестового стенда ubuntu-latest и измерения latency:
    1. Установите опцию --threshold-measure на встроенное измерение latency, которое создается bencher mock. См. документацию о --threshold-measure для получения более подробной информации. (например, --threshold-measure latency)
    2. Установите опцию --threshold-test на t-критерий Стьюдента (t_test). См. документацию о --threshold-test для получения полной информации. (например, --threshold-test t_test)
    3. Установите опцию --threshold-max-sample-size на максимальный размер выборки 64. См. документацию о --threshold-max-sample-size для получения более подробной информации. (например, --threshold-max-sample-size 64)
    4. Установите опцию --threshold-upper-boundary на верхнюю границу 0.99. См. документацию о --threshold-upper-boundary для получения более подробной информации. (например, --threshold-upper-boundary 0.99)
    5. Установите флаг --thresholds-reset, чтобы только указанное пороговое значение было активным. См. документацию о --thresholds-reset для получения полной информации. (например, --thresholds-reset)
  14. Установите флаг --error-on-alert, чтобы команда завершалась с ошибкой, если будет сформировано оповещение. См. документацию о --error-on-alert для получения полной информации. (например, --error-on-alert)
  15. Установите опцию --adapter на формат метрик Bencher в формате JSON (json), который сгенерирован bencher mock. См. Адаптеры для бенчмарк-харнесов для получения полной информации. (например, --adapter json)
  16. Установите опцию --github-actions на токен аутентификации API GitHub, чтобы отправить результаты в виде комментария GitHub Checks, используя переменную окружения GITHUB_TOKEN для GitHub Actions. См. документацию о --github-actions для получения более подробной информации. (например, --github-actions '${{ secrets.GITHUB_TOKEN }}')
  17. Укажите аргументы для команды бенчмарков. См. документацию о команде бенчмарков для получения полной информации. (например, bencher mock)

Pull Requests

Чтобы отлавливать регрессии производительности в Pull Requests, вам нужно будет запускать свои тесты производительности на PRs. Если вы ожидаете иметь PR только из веток внутри того же репозитория, тогда вы можете просто создать другой workflow для запуска on событий pull_request из того же репозитория.

⚠️ Это решение работает только если все PR из того же репозитория! См. Pull Requests из Fork ниже.

.github/workflows/pr_benchmarks.yml
on:
  pull_request:
    types: [opened, reopened, edited, synchronize]


jobs:
  benchmark_pr_branch:
    name: Continuous Benchmarking PRs with Bencher
    # DO NOT REMOVE: For handling Fork PRs see Pull Requests from Forks
    if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
    permissions:
      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

  1. Создайте файл workflow GitHub Actions. (пример: .github/workflows/pr_benchmarks.yml)

  2. Запустите на событиях pull_request:

    • opened - Pull request был создан.
    • reopened - Ранее закрытый pull request был переоткрыт.
    • edited - Название или тело pull request было отредактировано, или базовая ветка pull request была изменена.
    • synchronize - Ветка head pull request была обновлена. Например, ветка head была обновлена из базовой ветки или новые коммиты были добавлены в ветку head.

    См. документацию GitHub Actions on и документацию GitHub Actions pull_request для полного обзора. (пример: on: pull_request: types: [opened, reopened, edited, synchronize])

  3. Создайте job GitHub Actions. (пример: jobs: benchmark_pr_branch)

  4. Запустите на событиях pull_request только в том случае, если pull request из того же репозитория. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! Для обработки Fork PRs см. Pull Requests из Fork ниже. (пример: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

  5. Установите разрешения для GITHUB_TOKEN на write для checks и pull-requests. В зависимости от настроек GitHub, это может не требоваться. Но для всех организаций и личных репозиториев, созданных после 02 февраля 2023, это поведение является поведением по умолчанию. См. документацию GitHub для полного обзора. (пример: permissions: checks: write pull-requests: write)

  6. Установите тип машины, на которой будет выполняться job. См. документацию GitHub Actions runs-on для полного обзора. (пример: runs-on: ubuntu-latest)

  7. Проверьте исходный код ветки PR. (пример: uses: actions/checkout@v6)

  8. Установите Bencher CLI с использованием GitHub Action. (пример: uses: bencherdev/bencher@main)

  9. Используйте bencher run CLI подкоманду для запуска тестов производительности ветки pull request. См. подкоманду bencher run CLI для полного обзора. (пример: bencher run)

  10. Установите опцию --project на идентификатор проекта. См. документацию --project для подробностей. (пример: --project project-abc4567-wxyz123456789)

  11. Установите опцию --key на секрет репозитория BENCHER_API_KEY. См. документацию --key для подробностей. (пример: --key '${{ secrets.BENCHER_API_KEY }}')

  12. Установите опцию --branch на имя ветки PR используя переменную окружения GITHUB_HEAD_REF по умолчанию GitHub Actions. См. документацию --branch для полного обзора. (пример: --branch "$GITHUB_HEAD_REF")

  13. Установите начальную точку для ветки PR:

    1. Установите опцию --start-point на стартовую точку ветки PR используя переменную окружения GITHUB_BASE_REF по умолчанию GitHub Actions. См. документацию --start-point для полного обзора. (пример: --start-point "$GITHUB_BASE_REF")
    2. Установите опцию --start-point-hash на git хеш стартовой точки ветки PR используя событие pull_request GitHub Actions. См. документацию --start-point-hash для полного обзора. (пример: --start-point-hash '${{ github.event.pull_request.base.sha }}')
    3. Установите флаг --start-point-clone-thresholds, чтобы клонировать пороги из стартовой точки. См. документацию --start-point-clone-thresholds для полного обзора. (пример: --start-point-clone-thresholds)
    4. Установите флаг --start-point-reset, чтобы всегда сбрасывать ветку PR в стартовую точку. Это предотвратит дрейф данных тестов производительности. См. документацию --start-point-reset для полного обзора. (пример: --start-point-reset)

  14. Установите опцию --testbed на имя Testbed. Это, вероятно, должно совпадать с машиной, выбранной в runs-on. См. документацию --testbed для подробностей. (пример: --testbed ubuntu-latest)

  15. Установите флаг --error-on-alert, чтобы команда завершалась неудачей, если генерируется предупреждение. См. документацию --error-on-alert для полного обзора. (пример: --error-on-alert)

  16. Установите опцию --adapter на Bencher Metric Format JSON (json), который генерируется bencher mock. См. адаптеры тестовых сред для полного обзора. (пример: --adapter json)

  17. Установите опцию --github-actions на токен аутентификации API GitHub для публикации результатов как проверка GitHub и комментарий к Pull Request с использованием переменной окружения GITHUB_TOKEN. См. документацию --github-actions для подробностей. (пример: --github-actions '${{ secrets.GITHUB_TOKEN }}')

  18. Укажите аргументы команды теста производительности. См. команду теста производительности для полного обзора. (пример: bencher mock)

Чтобы очистить PR-ветку после закрытия PR, вы можете создать отдельный workflow, который будет запускаться on событиях типа pull_request с типом closed. Этот workflow архивирует PR-ветку с помощью команды bencher archive.

.github/workflows/pr_benchmarks_closed.yml
on:
  pull_request:
    types: [closed]


jobs:
  archive_pr_branch:
    name: Archive closed PR branch with Bencher
    # DO NOT REMOVE: For handling Fork PRs see Pull Requests from Forks
    if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@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"

  1. Создайте файл workflow для GitHub Actions. (например, .github/workflows/pr_benchmarks_closed.yml)

  2. Запускать на событиях pull_request:

    • closed - запрос на включение изменений был закрыт.

    См. документацию по GitHub Actions on и документацию по GitHub Actions pull_request для полного обзора. (например, on: pull_request: types: [closed])

  3. Создайте job для GitHub Actions. (например, jobs: archive_pr_branch)

  4. Запускайте на событиях pull_request только если запрос на включение изменений из того же репозитория. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! Для обработки Fork PR см. ниже Запросы на включение изменений из форков. (например, if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

  5. Установите тип машины, на которой будет выполняться работа. См. документацию по GitHub Actions runs-on для полного обзора. (например, runs-on: ubuntu-latest)

  6. Выполните проверку исходного кода PR-ветки. (например, uses: actions/checkout@v6)

  7. Установите Bencher CLI, используя GitHub Action. (например, uses: bencherdev/bencher@main)

  8. Используйте подкоманду CLI bencher archive для архивирования PR-ветки. (например, bencher archive)

  9. Установите для опции --project значение идентификатора проекта (slug). См. документацию по --project опции для более подробной информации. (например, --project project-abc4567-wxyz123456789)

  10. Установите для опции --key значение секрета Репозитория BENCHER_API_KEY. См. документацию по --key опции для более подробной информации. (например, --key '${{ secrets.BENCHER_API_KEY }}')

  11. Установите для опции --branch значение имени PR-ветки, используя переменную среды по умолчанию GitHub Actions GITHUB_HEAD_REF. (например, --branch "$GITHUB_HEAD_REF")


Запросы на вытягивание из форков

Если вы планируете принимать запросы на вытягивание из форков, как это часто бывает в публичных open source проектах, то вам потребуется немного по-другому с этим справляться. По соображениям безопасности, такие данные, как ваш BENCHER_API_KEY и GITHUB_TOKEN, недоступны в GitHub Actions для запросов на вытягивание из форков. То есть, если внешний участник открывает PR из форка, приведенный выше пример не будет работать. Смотрите это описание безопасности от лаборатории GitHub и этот пост в блоге для полного обзора о предотвращении атак pwn requests.

Это безопасный и рекомендуемый способ добавления Непрерывного Бенчмаркинга к запросам на вытягивание из форков. Он требует двух отдельных рабочих процессов. Первый рабочий процесс запускается и кэширует результаты бенчмаркинга в контексте pull_request. Там недоступны такие секреты, как ваш BENCHER_API_KEY и GITHUB_TOKEN. Затем второй рабочий процесс загружает кешированные результаты бенчмаркинга в контексте workflow_run и загружает их в Bencher. Это работает, потому что workflow_run запускается в контексте основной ветки репозитория, где доступны такие секреты, как ваш BENCHER_API_KEY и GITHUB_TOKEN. Номер запроса на вытягивание, ветка источника и базовая ветка, используемые в первоначальном рабочем процессе pull_request, также должны быть явно переданы в рабочий процесс workflow_run, так как они там недоступны. Эти рабочие процессы будут выполняться только если они существуют в основной ветке. Смотрите использование данных от запускающего рабочего процесса для полного обзора.

.github/workflows/fork_pr_benchmarks_run.yml
name: Run Benchmarks


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


jobs:
  benchmark_fork_pr_branch:
    name: Run Fork PR Benchmarks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@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 }}

  1. Создайте первый файл workflow GitHub Actions. (например: .github/workflows/fork_pr_benchmarks_run.yml)

  2. Назовите этот workflow так, чтобы его можно было использовать во втором workflow. (например: name: Run Benchmarks)

  3. Запускайте на событиях pull_request:

    • opened - Создан новый pull request.
    • reopened - Повторно открыт ранее закрытый pull request.
    • edited - Изменен заголовок или тело pull request, или изменена базовая ветка pull request.
    • synchronize - Обновлена головная ветка pull request. Например, головная ветка была обновлена из базовой ветки или в головную ветку были отправлены новые коммиты.

    См. документацию по on в GitHub Actions и документацию по pull_request в GitHub Actions для полного обзора. (например: on: pull_request: types: [opened, reopened, edited, synchronize])

  4. Создайте job в GitHub Actions. (например: jobs: benchmark_fork_pr_branch)

  5. Установите тип машины, на которой будет выполняться job. См. документацию по runs-on в GitHub Actions для полного обзора. (например: runs-on: ubuntu-latest)

  6. Выполните checkout исходного кода ветки fork PR. (например: uses: actions/checkout@v6)

  7. Запустите тесты производительности и сохраните результаты в файл. (например: /bin/echo '{ ... }' > benchmark_results.json)

  8. Загрузите файл с результатами тестов производительности как артефакт. (например: uses: actions/upload-artifact@v4)

  9. Загрузите объект события pull_request как артефакт. (например: uses: actions/upload-artifact@v4)

.github/workflows/fork_pr_benchmarks_track.yml
name: Track Benchmarks with Bencher


on:
  workflow_run:
    workflows: [Run Benchmarks]
    types: [completed]


jobs:
  track_fork_pr_branch:
    if: github.event.workflow_run.conclusion == 'success'
    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"
  1. Создайте первый файл workflow для GitHub Actions. (например, .github/workflows/fork_pr_benchmarks_track.yml)
  2. Назовите этот workflow вторым workflow. (например, name: Track Benchmarks with Bencher)
  3. Свяжите два workflow с помощью события workflow_run. (например, on: workflow_run: ...)
  4. Создайте job для GitHub Actions. (например, jobs: track_fork_pr_branch)
  5. Выполните эту задачу только в случае успешного завершения предыдущего workflow, используя событие workflow_run GitHub Actions. (например, if: github.event.workflow_run.conclusion == 'success')
  6. Установите разрешения для GITHUB_TOKEN на write для checks и pull-requests. В зависимости от ваших настроек GitHub, это может не требоваться. Однако для всех организаций и персональных репозиториев, созданных после 02 февраля 2023 года, это поведение по умолчанию. Полный обзор см. в документации GitHub. (например, permissions: checks: write pull-requests: write)
  7. Установите тип компьютера, на котором будет выполняться задача. Полный обзор см. в документации runs-on для GitHub Actions. (например, runs-on: ubuntu-latest)
  8. Задайте результаты бенчмарков и файлы объектов события pull_request в качестве переменных среды. (например, env: ...)
  9. Скачайте кешированные результаты бенчмарков и событие pull_request с помощью GitHub Action action-download-artifact. (например, uses: dawidd6/action-download-artifact@v6)
  10. Экспортируйте необходимые данные из события pull_request как промежуточные переменные среды. (например, core.exportVariable(...))
  11. Установите Bencher CLI с помощью GitHub Action. (например, uses: bencherdev/bencher@main)
  12. Используйте подкоманду CLI bencher run для отслеживания бенчмарков брэнча в вашем форке. Полный обзор см. в подкоманде bencher run для CLI. (например, bencher run)
  13. Установите параметр --project в значение Project slug. Подробности смотрите в документации --project. (например, --project project-abc4567-wxyz123456789)
  14. Установите параметр --key в значение секрета Repository BENCHER_API_KEY. Подробности смотрите в документации --key. (например, --key '${{ secrets.BENCHER_API_KEY }}')
  15. Установите параметр --branch на имя ветки PR форка с использованием промежуточной переменной среды. Полный обзор см. в документации --branch. (например, --branch "$PR_HEAD")
  16. Установите параметр --hash в git hash ветки PR форка с использованием промежуточной переменной среды. Полный обзор см. в документации --hash. (например, --hash "$PR_HEAD_SHA")
  17. Установите Начальную Точку для ветки PR форка:
    1. Установите параметр --start-point на начальную точку ветки PR форка с использованием промежуточной переменной среды. Полный обзор см. в документации --start-point. (например, --start-point "$PR_BASE")
    2. Установите параметр --start-point-hash в git hash начальной точки ветки PR форка с использованием промежуточной переменной среды. Полный обзор см. в документации --start-point-hash. (например, --start-point-hash "$PR_BASE_SHA")
    3. Установите флаг --start-point-clone-thresholds, чтобы клонировать Пороги с начальной точки. Полный обзор см. в документации --start-point-clone-thresholds. (например, --start-point-clone-thresholds)
    4. Установите флаг --start-point-reset для всегда сбрасывания ветки PR форка к начальной точке. Это предотвратит сдвиг данных бенчмарков. Полный обзор см. в документации --start-point-reset. (например, --start-point-reset)
  18. Установите параметр --testbed на имя Testbed. Это должно совпадать с машиной, выбранной в runs-on. Подробности смотрите в документации --tested. (например, --testbed ubuntu-latest)
  19. Установите флаг --error-on-alert, чтобы команда завершилась неудачно, если сгенерируется Уведомление. Полный обзор см. в документации --error-on-alert. (например, --error-on-alert)
  20. Установите параметр --adapter в значение Bencher Metric Format JSON (json), который генерируется bencher mock. Полный обзор см. в документации адаптеров. (например, --adapter json)
  21. Установите параметр --github-actions на значение токена аутентификации GitHub API для публикации результатов в виде проверки GitHub и комментария к Pull Request, используя переменную среды GITHUB_TOKEN GitHub Actions. Подробности смотрите в документации --github-actions. (например, --github-actions '${{ secrets.GITHUB_TOKEN }}')
  22. Установите параметр --ci-number на номер pull request, используя промежуточную переменную среды. Подробности смотрите в документации --ci-number. (например, --ci-number "$PR_NUMBER")
  23. Установите параметр --file на путь к файлу с результатами бенчмарков. Полный обзор см. в документации о команде бенчмарков. (например, --file "$BENCHMARK_RESULTS")

Чтобы очистить ветку PR форка после закрытия её PR, вы можете создать отдельный рабочий процесс, который будет запускаться на события pull_request_target с типом closed. Этот рабочий процесс заархивирует ветку PR форка с помощью команды bencher archive.

.github/workflows/fork_pr_benchmarks_closed.yml
on:
  pull_request_target:
    types: [closed]


jobs:
  archive_fork_pr_branch:
    name: Archive closed fork PR branch with Bencher
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@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"

  1. Создайте файл workflow для GitHub Actions. (например, .github/workflows/fork_pr_benchmarks_closed.yml)

  2. Запускайте на событиях pull_request_target:

    • closed - Пул-реквест был закрыт.

    См. документацию по GitHub Actions on и документацию по GitHub Actions pull_request_target для полного обзора. (например, on: pull_request_target: types: [closed])

  3. Создайте задание job для GitHub Actions. (например, jobs: archive_pr_branch)

  4. Установите тип машины, на которой будет выполнено задание. См. документацию по GitHub Actions runs-on для полного обзора. (например, runs-on: ubuntu-latest)

  5. Выполните проверку исходного кода ветки PR. (например, uses: actions/checkout@v6)

  6. Установите Bencher CLI, используя действие GitHub Action. (например, uses: bencherdev/bencher@main)

  7. Используйте подкоманду CLI bencher archive для архивирования ветки PR. (например, bencher archive)

  8. Установите опцию --project на идентификатор проекта. Подробнее см. в документации по --project. (например, --project project-abc4567-wxyz123456789)

  9. Установите опцию --key на секрет репозитория BENCHER_API_KEY. Подробнее см. в документации по --key. (например, --key '${{ secrets.BENCHER_API_KEY }}')

  10. Установите опцию --branch на имя ветки PR, используя переменную среды по умолчанию GITHUB_HEAD_REF для GitHub Actions. (например, --branch "$GITHUB_HEAD_REF")


Pull Requests на выделенном оборудовании

У GitHub Actions есть Self-Hosted раннеры, но для них нужно использовать их шумный бинарный файл GitHub Actions Runner. Bencher Bare Metal запускает бенчмарки на выделенном парке оборудования bare metal с помощью специально созданного малошумного раннера бенчмарков. Кроме того, Bencher Bare Metal поддерживает PR из форков, а GitHub Actions Runner нет.

После перехода на Bencher Bare Metal вам не захочется, чтобы job GitHub Actions работал все время, пока он ждет Bencher. Для этого Bencher использует разделенный workflow, благодаря которому GitHub Actions может асинхронно ожидать Job в Bencher Bare Metal.

Следующий пример предназначен для веток в том же репозитории. Используйте этот шаблон вместе с workflow Pull Requests из Fork выше, чтобы запускать бенчмарки на выделенном оборудовании для PR из форков.

.github/workflows/pr_bare_metal_benchmarks.yml
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
  1. Создайте первый файл workflow GitHub Actions. (пример: .github/workflows/pr_bare_metal_benchmarks.yml)
  2. Запустите на событиях pull_request, как в разделе Pull Requests выше. (пример: on: pull_request: types: [opened, reopened, edited, synchronize])
  3. Создайте job GitHub Actions. (пример: jobs: submit_pr_benchmarks)
  4. Запустите на событиях pull_request только в том случае, если pull request из того же репозитория. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! Для обработки Fork PRs см. Pull Requests из Fork выше. (пример: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)
  5. Установите разрешения для GITHUB_TOKEN на write для checks. Первый workflow запускает проверку GitHub и не публикует комментарий. (пример: permissions: checks: write)
  6. Установите тип машины, на которой будет выполняться job. Он только отправляет Job, поэтому достаточно небольшой машины. (пример: runs-on: ubuntu-latest)
  7. Получите исходный код ветки PR. (пример: uses: actions/checkout@v6)
  8. Установите Bencher CLI с использованием GitHub Action. (пример: uses: bencherdev/bencher@main)
  9. Используйте bencher run CLI подкоманду для отправки бенчмарков ветки pull request. См. подкоманду bencher run CLI для полного обзора. (пример: bencher run)
  10. Установите опцию --project на идентификатор проекта. См. документацию --project для подробностей. (пример: --project project-abc4567-wxyz123456789)
  11. Установите опцию --key на секрет репозитория BENCHER_API_KEY. См. документацию --key для подробностей. (пример: --key '${{ secrets.BENCHER_API_KEY }}')
  12. Установите опцию --branch на имя ветки PR используя переменную окружения GITHUB_HEAD_REF по умолчанию GitHub Actions. См. документацию --branch для полного обзора. (пример: --branch "$GITHUB_HEAD_REF")
  13. Установите начальную точку для ветки PR, как в разделе Pull Requests выше. См. документацию --start-point для полного обзора. (пример: --start-point "$GITHUB_BASE_REF")
  14. Установите опцию --adapter на Bencher Metric Format JSON (json), который генерирует bencher mock. См. адаптеры тестовых харнесов для полного обзора. (пример: --adapter json)
  15. Установите опцию --image на ваш образ для выделенного оборудования. См. документацию --image для полного обзора. (пример: --image project-abc4567-wxyz123456789:latest)
  16. Установите флаг --detach, чтобы завершиться сразу после отправки Job. См. документацию --detach для подробностей. (пример: --detach)
  17. Установите опцию --github-actions на токен аутентификации API GitHub, чтобы запустить проверку GitHub, используя переменную окружения GITHUB_TOKEN GitHub Actions. См. документацию --github-actions для подробностей. (пример: --github-actions '${{ secrets.GITHUB_TOKEN }}')
  18. Установите опцию --ci-callback-token на секрет репозитория BENCHER_CALLBACK_TOKEN, чтобы Bencher мог отправить событие repository_dispatch, когда Job завершится. См. документацию --ci-callback-token для подробностей. (пример: --ci-callback-token '${{ secrets.BENCHER_CALLBACK_TOKEN }}')
  19. Укажите команду бенчмарка, которая выполняется в образе. Команда передается точке входа образа, если она есть (см. опцию --entrypoint). См. команду бенчмарка для полного обзора. (пример: bencher mock)
.github/workflows/pr_bare_metal_benchmarks_attach.yml
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 }}'
  1. Создайте второй файл workflow GitHub Actions в ветке по умолчанию. GitHub запускает workflow repository_dispatch только из ветки по умолчанию, поэтому, пока этого файла там нет, проверка GitHub, которую запускает первый workflow, остается выполняющейся. (пример: .github/workflows/pr_bare_metal_benchmarks_attach.yml)
  2. Запустите на событиях repository_dispatch типа bencher_run. См. документацию GitHub Actions on и документацию GitHub Actions repository_dispatch для полного обзора. (пример: on: repository_dispatch: types: [bencher_run])
  3. Создайте job GitHub Actions. (пример: jobs: attach_pr_benchmarks)
  4. Установите разрешения для GITHUB_TOKEN на write для checks и pull-requests. (пример: permissions: checks: write pull-requests: write)
  5. Установите тип машины, на которой будет выполняться job. Job уже завершен, поэтому этот job только публикует результаты. (пример: runs-on: ubuntu-latest)
  6. Установите Bencher CLI с использованием GitHub Action. Получать исходный код не нужно. (пример: uses: bencherdev/bencher@main)
  7. Передайте UUID Job из события через промежуточную переменную окружения, а не напрямую в run:, как того требуют рекомендации GitHub по защите от внедрения скриптов. (пример: env: JOB_UUID: ${{ github.event.client_payload.bencher.job }})
  8. Используйте bencher run CLI подкоманду для подключения к Job. См. подкоманду bencher run CLI для полного обзора. (пример: bencher run)
  9. Установите опцию --project на идентификатор проекта. Если в репозитории несколько Проектов, передайте github.event.client_payload.bencher.project через переменную окружения тем же способом и заключите ее в кавычки (пример: --project "$PROJECT_SLUG"). См. документацию --project для подробностей. (пример: --project project-abc4567-wxyz123456789)
  10. Установите опцию --key на секрет репозитория BENCHER_API_KEY. См. документацию --key для подробностей. (пример: --key '${{ secrets.BENCHER_API_KEY }}')
  11. Установите опцию --job на UUID Job в кавычках. См. документацию --job для полного обзора. (пример: --job "$JOB_UUID")
  12. Установите флаг --error-on-alert, чтобы команда завершалась неудачей при генерации предупреждения. Событие несет только данные, поэтому опции, которые определяют, как публикуются результаты, например --ci-only-on-alert и --ci-public-links, тоже указываются здесь, во втором workflow. См. документацию --error-on-alert для полного обзора. (пример: --error-on-alert)
  13. Установите опцию --github-actions на токен аутентификации API GitHub, чтобы публиковать результаты как проверку GitHub и комментарий к Pull Request, используя переменную окружения GITHUB_TOKEN GitHub Actions. Явно заданные здесь --ci-number или --ci-id имеют приоритет над событием. См. документацию --github-actions для подробностей. (пример: --github-actions '${{ secrets.GITHUB_TOKEN }}')


🐰 Поздравляем! Вы научились использовать Bencher в GitHub Actions! 🎉


Продолжить: Обзор бенчмаркинга ➡

🤖 Этот документ был автоматически переведён с помощью ИИ. Он может быть неточным и содержать ошибки. Если вы обнаружите какие-либо ошибки, откройте проблему на GitHub.

Published: Fri, October 27, 2023 at 8:40:00 AM UTC | Last Updated: Sun, September 27, 2026 at 12:00:00 AM UTC