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


В зависимости от вашего случая использования, вы можете настроить Непрерывное бенчмаркинг в GitHub Actions для вашего:

Убедитесь, что вы создали токен API и установили его как секрет Репозитория под названием BENCHER_API_TOKEN перед тем как продолжить! Перейти к Ваш Репозиторий -> Настройки -> Секреты и переменные -> Действия -> Новый секрет репозитория. Назовите секрет BENCHER_API_TOKEN и установите значение секрета вашим токеном API.

В GitHub Actions, секреты не передаются на runner, когда workflow запускается из форкнутого репозитория. Поэтому вам необходимо использовать ветку из того же репозитория, когда добавляете любой из workflow, приведённых ниже, в ваш репозиторий через pull request. Если вы попытаетесь добавить Bencher через pull request из форка, то секрет BENCHER_API_TOKEN не будет доступен. ${{ secrets.BENCHER_API_TOKEN }} будет пустой строкой.

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

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

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. Создайте файл workflow для GitHub Actions. (например, .github/workflows/base_benchmarks.yml)
  2. Запустите на событиях push в ветку main. Смотрите документацию on GitHub Actions и документацию push GitHub Actions для полного обзора. (например: on: push: branches: main)
  3. Создайте job для GitHub Actions. (например: jobs: benchmark_base_branch)
  4. Установите тип машины, на которой будет выполняться задание. Смотрите документацию runs-on GitHub Actions для полного обзора. (например: runs-on: ubuntu-latest)
  5. Выполните checkout исходного кода вашей основной ветки. (например: uses: actions/checkout@v4)
  6. Установите Bencher CLI, используя действие GitHub. (например: uses: bencherdev/bencher@main)
  7. Используйте подкоманду CLI bencher run для запуска бенчмарков вашей ветки main. Смотрите подкоманду CLI bencher run для полного обзора. (например: bencher run)
  8. Установите опцию --project в слаг проекта. Смотрите документацию --project для более подробной информации. (например: --project save-walter-white-1234abcd)
  9. Установите опцию --token в секрет Репозитория BENCHER_API_TOKEN. Смотрите документацию --token для более подробной информации. (например: --token '${{ secrets.BENCHER_API_TOKEN }}')
  10. Установите опцию --branch в имя ветки. Смотрите выбор ветки для полного обзора. (например: --branch main)
  11. Установите опцию --testbed в имя тестовой среды. Это должно, вероятно, совпадать с машиной, выбранной в runs-on. Смотрите документацию --testbed для более подробной информации. (например: --testbed ubuntu-latest)
  12. Установите опцию --adapter в желаемый адаптер инструмента для бенчмаркинга. Смотрите адаптеры инструментов для бенчмаркинга для полного обзора. (например: --adapter json)
  13. Установите флаг --err, чтобы команда завершалась с ошибкой, если сгенерировано предупреждение. Смотрите Пороги и Предупреждения для полного обзора. (например: --err)
  14. Укажите аргументы команды бенчмарка. Смотрите команду бенчмарка для полного обзора. (например: bencher mock)

Пулл Реквесты

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

⚠️ Это решение работает только в том случае, если все PRs из одного и того же репозитория! Смотрите Пулл Реквесты из форков ниже.

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 }}' \
--branch-reset \
--testbed ubuntu-latest \
--adapter json \
--err \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
bencher mock
  1. Создайте файл workflow в GitHub Actions. (например: .github/workflows/pr_benchmarks.yml)

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

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

    Смотрите документацию 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 только в том случае, если пулл реквест из того же самого репозитория. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! Для работы с пулл реквестами из форков см. Пулл Реквесты из форков ниже. (например: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

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

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

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

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

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

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

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

  12. Установите опцию --branch на имя ветки PR, используя контекст GitHub Actions github. Смотрите выбор ветки для полного обзора. (например: --branch '${{ github.head_ref }}')

  13. Установите опцию --branch-start-point на исходную точку базовой ветки PR, используя контекст GitHub Actions github. Смотрите выбор ветки для полного обзора. (например: --branch-start-point '${{ github.base_ref }}')

  14. Установите опцию --branch-start-point-hash на хэш исходной точки базовой ветки PR, используя событие GitHub Actions pull_request. Смотрите выбор ветки для полного обзора. (например: --branch-start-point-hash '${{ github.event.pull_request.base.sha }}')

  15. Установите флаг --branch-reset, чтобы всегда сбрасывать ветку до исходной точки. Это предотвратит дрейф данных измерений. Смотрите выбор ветки для полного обзора. (например: --branch-reset)

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

  17. Установите опцию --adapter на желаемый адаптер для выполнения бенчмарков. Смотрите адаптеры для выполнения бенчмарков для полного обзора. (например: --adapter json)

  18. Установите флаг --err, чтобы команда завершалась неудачно, если будет создано предупреждение. Смотрите Пороги и предупреждения для полного обзора. (например: --err)

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

  20. Укажите аргументы команды bенчмарка. Смотрите команду bенчмарка для полного обзора. (например: bencher mock)


Pull Request’ы из форков

Если вы планируете принимать pull request’ы из форков, как это часто бывает в публичных проектах с открытым исходным кодом, вам потребуется немного иначе подходить к вопросу. Из соображений безопасности, такие секреты, как ваш BENCHER_API_TOKEN и GITHUB_TOKEN, недоступны в GitHub Actions для pull request’ов из форков. То есть, если внешний участник создает pull request из форка, приведенный выше пример не сработает. Есть два варианта для pull request’ов из форков:

Смотрите этот анализ GitHub Security Lab и этот блог пост для получения полного обзора по предотвращению pwn запросов.

Сравнительный анализ Fork PR и Загрузка с Основной Ветки

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

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. Создайте первый файл workflow для GitHub Actions. (например, .github/workflows/run_fork_pr_benchmarks.yml)

  2. Назовите этот рабочий процесс, чтобы его можно было использовать во втором рабочем процессе. (например, name: Запуск и кеширование сравнительного анализа)

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

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

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

  4. Создайте задачу для GitHub Actions. (например, jobs: benchmark_fork_pr_branch)

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

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 }}' \
--branch-reset \
--testbed ubuntu-latest \
--adapter json \
--err \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
--ci-number '${{ env.PR_NUMBER }}' \
--file "$BENCHMARK_RESULTS"
  1. Создайте второй файл workflow для GitHub Actions. (например, .github/workflows/track_fork_pr_benchmarks.yml)
  2. Назовите этот второй рабочий процесс. (например, name: Отслеживание сравнительных анализов с помощью Bencher)
  3. Свяжите два рабочих процесса с помощью события workflow_run. (например, on: workflow_run: ...)
  4. Создайте задачу для GitHub Actions. (например, jobs: track_fork_pr_branch)
  5. Запускайте эту задачу только если выполнение предыдущего рабочего процесса было успешным, используя событие GitHub Actions workflow_run. (например, if: github.event.workflow_run.conclusion == 'success')
  6. Установите тип машины, на которой будет выполняться задача. См. документацию GitHub Actions runs-on для полного обзора. (например, runs-on: ubuntu-latest)
  7. Установите имена файлов с результатами сравнительного анализа и объектом события pull_request как переменные окружения. (например, env: ...)
  8. Загрузите кешированные результаты сравнительного анализа и событие pull_request. (например, uses: actions/github-script@v6)
  9. Распакуйте кешированные результаты сравнительного анализа и событие pull_request. (например, unzip ...)
  10. Экспортируйте необходимые данные из события pull_request как переменные окружения. (например, core.exportVariable(...))
  11. Установите Bencher CLI, используя GitHub Action. (например, uses: bencherdev/bencher@main)
  12. Используйте подкоманду bencher run CLI для отслеживания ваших бенчмарков из ветки fork pull request. См. подкоманду bencher run CLI для полного обзора. (например, bencher run)
  13. Установите опцию --project на slug проекта. См. документацию по опции --project для более подробной информации. (например, --project save-walter-white-1234abcd)
  14. Установите опцию --token на секрет Repository BENCHER_API_TOKEN. См. документацию по опции --token для более подробной информации. (например, --token '${{ secrets.BENCHER_API_TOKEN }}')
  15. Установите опцию --branch на отформатированный номер fork PR, используя событие GitHub Actions pull_request. См. выбор ветки для полного обзора. (например, --branch '${{ env.PR_HEAD }}')
  16. Установите опцию --branch-start-point на начальную точку базовой ветки fork PR, используя событие GitHub Actions pull_request. См. выбор ветки для полного обзора. (например, --branch-start-point '${{ env.PR_BASE }}')
  17. Установите опцию --branch-start-point-hash на хэш начальной точки базовой ветки fork PR, используя событие GitHub Actions pull_request. См. выбор ветки для полного обзора. (например, --branch-start-point-hash '${{ env.PR_BASE_SHA }}')
  18. Установите флаг --branch-reset, чтобы всегда сбрасывать ветку до начальной точки. Это предотвратит дрейф данных бенчмарков. См. выбор ветки для полного обзора. (например, --branch-reset)
  19. Установите опцию --testbed на имя тестовой машины. Это должно соответствовать выбранной машине в runs-on. См. документацию по опции --tested для более подробной информации. (например, --testbed ubuntu-latest)
  20. Установите опцию --adapter на нужный адаптер сравнительного анализа. См. адаптеры сравнительного анализа для полного обзора. (например, --adapter json)
  21. Установите флаг --err, чтобы команда завершалась неудачей, если сгенерировано предупреждение. См. Пороги и Предупреждения для полного обзора. (например, --err)
  22. Установите опцию --github-actions на токен аутентификации GitHub API, чтобы опубликовать результаты в виде комментария к pull request, используя переменную окружения GITHUB_TOKEN GitHub Actions. См. документацию по опции --github-actions для более подробной информации. (например, --github-actions '${{ secrets.GITHUB_TOKEN }}')
  23. Установите опцию --ci-number на номер pull request. См. документацию по опции --ci-number для более подробной информации. (например, --ci-number '${{ env.PR_NUMBER }}')
  24. Установите опцию --file на путь к файлу с результатами сравнительного анализа. См. команду сравнения для полного обзора. (например, --file "$BENCHMARK_RESULTS")

Оценка Fork PR из целевой ветки с обязательными рецензентами

Для того чтобы гарантировать безопасность кода из fork pull request, этот GitHub Action проверяет, является ли fork из другого репозитория. Если fork из другого репозитория, то он должен быть проверен.

⚠️ Очень, очень важно тщательно проверять каждый fork PR перед одобрением! В противном случае это может привести к pwn request!

Если вы не хотите, чтобы это висело над вами, см. Оценка Fork PR и загрузка из основной ветки выше.

Чтобы настроить этот workflow, вам нужно создать две Среды GitHub Actions. Перейдите в Ваш репозиторий -> Настройки -> Среды -> Новая среда. Создайте две новые среды, internal и external. Среда internal не должна иметь Правила защиты развертывания. Однако среда external должна иметь Обязательные рецензенты, назначенные тем, кому доверено проверять fork PR перед оценкой. Полный обзор см. в этой статье в блоге.

Эта настройка работает, потому что pull_request_target выполняется в контексте целевой ветки pull request, где доступны секреты, такие как ваш BENCHER_API_TOKEN и GITHUB_TOKEN. Поэтому этот workflow будет выполняться только если он существует в целевой ветке. Избегайте установки секретов в качестве переменных среды, таких как GITHUB_TOKEN и BENCHER_API_TOKEN. Вместо этого явно передайте свои секреты в команду bencher run.

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 }}' \
--branch-reset \
--testbed ubuntu-latest \
--adapter json \
--err \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
bencher mock
  1. Создайте файл workflow в GitHub Actions. (например: .github/workflows/pr_target_benchmarks.yml)

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

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

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

  3. Создайте первую job GitHub Actions, чтобы проверить, требуется ли рецензия. (например: jobs: fork_pr_requires_review)

  4. Установите environment на internal, если и только если pull request из того же репозитория. В противном случае установите environment на external, что потребует одобрения рецензента для продолжения. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! (например: environment: ${{ (github.event.pull_request.head.repo.full_name == github.repository && 'internal') || 'external' }})

  5. Создайте вторую job GitHub Actions для запуска ваших бенчмарков. (например: benchmark_fork_pr_branch)

  6. Сделайте job benchmark_fork_pr_branch зависимой от job fork_pr_requires_review. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! Полный обзор см. в документации GitHub Actions needs. (например: needs: fork_pr_requires_review)

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

  8. Выполните checkout исходного кода fork PR. Поскольку pull_request_target выполняется в контексте целевой ветки pull request, вам все равно нужно выполнить checkout ветки pull request. (например: uses: actions/checkout@v4)

    • Укажите репозиторий fork PR (например: repository: ${{ github.event.pull_request.head.repo.full_name }})
    • Укажите хэш fork PR (например: ref: ${{ github.event.pull_request.head.sha }})
    • Не сохраняйте ваши учетные данные git (например: persist-credentials: false)
  9. Установите Bencher CLI, используя GitHub Action. (например: uses: bencherdev/bencher@main)

  10. Используйте подкоманду CLI bencher run для запуска бенчмарков вашей ветки fork PR. Полный обзор см. в подкоманде bencher run CLI. (например: bencher run)

  11. Установите параметр --project на слаг проекта. Подробности см. в документации --project. (например: --project save-walter-white-1234abcd)

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

  13. Установите параметр --branch на отформатированный номер fork PR, используя событие pull_request в GitHub Actions. Полный обзор см. в выбор ветки. (например: --branch '${{ github.event.number }}/merge')

  14. Установите параметр --branch-start-point на начальную точку базовой ветки fork PR, используя контекст github в GitHub Actions. Полный обзор см. в выбор ветки. (например: --branch-start-point '${{ github.base_ref }}')

  15. Установите параметр --branch-start-point-hash на хэш начальной точки базовой ветки fork PR, используя событие pull_request в GitHub Actions. Полный обзор см. в выбор ветки. (например: --branch-start-point-hash '${{ github.event.pull_request.base.sha }}')

  16. Установите флаг --branch-reset для всегда сброса ветки к начальной точке. Это предотвратит дрейф данных бенчмарков. Полный обзор см. в выбор ветки. (например: --branch-reset)

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

  18. Установите параметр --adapter на желаемый адаптер для бенчмарк-харнессов. Полный обзор см. в адаптерах бенчмарк-харнессов. (например: --adapter json)

  19. Установите флаг --err, чтобы команда завершалась с ошибкой при генерации предупреждения. Полный обзор см. в порогах и предупреждениях. (например: --err)

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

  21. Укажите параметры команды бенчмарк. Полный обзор см. в команда бенчмарк. (например: bencher mock)



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


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

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


Published: Fri, October 27, 2023 at 8:40:00 AM UTC | Last Updated: Thu, August 22, 2024 at 12:40:00 PM UTC