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


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

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

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_TOKEN secret will not be available. ${{ secrets.BENCHER_API_TOKEN }} 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@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
  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@v4)
  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 save-walter-white-1234abcd)
  10. Установите опцию --token на секрет Repositorий BENCHER_API_TOKEN. См. документацию о --token для получения более подробной информации. (например, --token '${{ secrets.BENCHER_API_TOKEN }}')
  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. Установите флаг --err, чтобы команда завершалась с ошибкой, если будет сформировано оповещение. См. документацию о --err для получения полной информации. (например, --err)
  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:
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
  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 для pull-requests. В зависимости от настроек GitHub, это может не требоваться. Но для всех организаций и личных репозиториев, созданных после 02 февраля 2023, это поведение является поведением по умолчанию. См. документацию GitHub для полного обзора. (пример: permissions: pull-requests: write)

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

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

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

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

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

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

  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. Установите флаг --err, чтобы команда завершалась неудачей, если генерируется предупреждение. См. документацию --err для полного обзора. (пример: --err)

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

  17. Установите опцию --github-actions на токен аутентификации API 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@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"
  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@v4)

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

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

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

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

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


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

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

Это безопасный и рекомендуемый способ добавления Непрерывного Бенчмаркинга к запросам на вытягивание из форков. Он требует двух отдельных рабочих процессов. Первый рабочий процесс запускается и кэширует результаты бенчмаркинга в контексте pull_request. Там недоступны такие секреты, как ваш BENCHER_API_TOKEN и GITHUB_TOKEN. Затем второй рабочий процесс загружает кешированные результаты бенчмаркинга в контексте workflow_run и загружает их в Bencher. Это работает, потому что workflow_run запускается в контексте основной ветки репозитория, где доступны такие секреты, как ваш BENCHER_API_TOKEN и 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@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. Создайте первый файл 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@v4)

  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'
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_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 "$PR_HEAD" \
--start-point "$PR_BASE" \
--start-point-hash "$PR_BASE_SHA" \
--start-point-clone-thresholds \
--start-point-reset \
--testbed ubuntu-latest \
--err \
--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. Запустите этот job только в случае успешного завершения предыдущего workflow, используя событие workflow_run GitHub Actions. (например, if: github.event.workflow_run.conclusion == 'success')
  6. Установите тип машины, на которой будет выполнено задание. См. документацию GitHub Actions runs-on для полного обзора. (например, runs-on: ubuntu-latest)
  7. Установите результаты бенчмарков и имена файлов объекта события pull_request как переменные окружения. (например, env: ...)
  8. Скачайте кешированные результаты бенчмарков и событие pull_request используя действие action-download-artifact GitHub Actions. (например, uses: dawidd6/action-download-artifact@v6)
  9. Экспортируйте необходимые данные из события pull_request как переменные окружения. (например, core.exportVariable(...))
  10. Установите Bencher CLI, используя GitHub Action. (например, uses: bencherdev/bencher@main)
  11. Используйте подкоманду CLI bencher run для отслеживания бенчмарков ветки форка pull. См. подкоманду CLI bencher run для полного обзора. (например, bencher run)
  12. Установите опцию --project на проектный ключ. См. документацию --project для более подробной информации. (например, --project save-walter-white-1234abcd)
  13. Установите опцию --token на секрет BENCHER_API_TOKEN репозитория. См. документацию --token для более подробной информации. (например, --token '${{ secrets.BENCHER_API_TOKEN }}')
  14. Установите опцию --branch на имя ветки форка PR, используя промежуточную переменную окружения. См. документацию --branch для полного обзора. (например, --branch "$PR_HEAD")
  15. Установите начальную точку для ветки форка PR:
    1. Установите опцию --start-point на начальную точку ветки форка PR, используя промежуточную переменную окружения. См. документацию --start-point для полного обзора. (например, --start-point "$PR_BASE")
    2. Установите опцию --start-point-hash на хэш git начальной точки ветки форка 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)
  16. Установите опцию --testbed на имя тестового стенда. Это, вероятно, должно совпадать с выбранной машиной в runs-on. См. документацию --tested для более подробной информации. (например, --testbed ubuntu-latest)
  17. Установите флаг --err для провала команды в случае генерации Предупреждения. См. документацию --err для полного обзора. (например, --err)
  18. Установите опцию --adapter на Bencher Metric Format JSON (json), который генерируется bencher mock. См. бенчмаркинг адаптеров для полного обзора. (например, --adapter json)
  19. Установите опцию --github-actions на токен аутентификации GitHub API для размещения результатов в комментарии к Pull Request, используя переменную окружения GITHUB_TOKEN GitHub Actions. См. документацию --github-actions для более подробной информации. (например, --github-actions '${{ secrets.GITHUB_TOKEN }}')
  20. Установите опцию --ci-number на номер pull request, используя промежуточную переменную окружения. См. документацию --ci-number для более подробной информации. (например, --ci-number "$PR_NUMBER")
  21. Установите опцию --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@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"
  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@v4)

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

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

  8. Установите опцию --project на идентификатор проекта. Подробнее см. в документации по --project. (например, --project save-walter-white-1234abcd)

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

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



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


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

🤖 Этот документ был автоматически создан OpenAI GPT-4. Оно может быть неточным и содержать ошибки. Если вы обнаружите какие-либо ошибки, откройте проблему на GitHub.


Published: Fri, October 27, 2023 at 8:40:00 AM UTC | Last Updated: Mon, November 4, 2024 at 7:40:00 AM UTC