Как использовать Bencher в GitHub Actions
В зависимости от вашего случая использования, вы можете настроить Непрерывное бенчмаркинг в GitHub Actions для вашего:
- Основного ветки
- Запросов на вытягивание (Pull Requests)
- Запросов на вытягивание из форков
- ⛑️ Безопаснее: Бенчмаркинг PR из форка и загрузка из основной ветки
- ⚠️ Рискованнее: Бенчмаркинг PR из форка из целевой ветки с обязательными рецензентами
Убедитесь, что вы создали токен 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).
- Создайте файл
workflow
для GitHub Actions. (например,.github/workflows/base_benchmarks.yml
) - Запустите на событиях
push
в веткуmain
. Смотрите документациюon
GitHub Actions и документациюpush
GitHub Actions для полного обзора. (например:on: push: branches: main
) - Создайте
job
для GitHub Actions. (например:jobs: benchmark_base_branch
) - Установите тип машины, на которой будет выполняться задание.
Смотрите документацию
runs-on
GitHub Actions для полного обзора. (например:runs-on: ubuntu-latest
) - Выполните checkout исходного кода вашей основной ветки.
(например:
uses: actions/checkout@v4
) - Установите Bencher CLI, используя действие GitHub.
(например:
uses: bencherdev/bencher@main
) - Используйте подкоманду CLI
bencher run
для запуска бенчмарков вашей веткиmain
. Смотрите подкоманду CLIbencher run
для полного обзора. (например:bencher run
) - Установите опцию
--project
в слаг проекта. Смотрите документацию--project
для более подробной информации. (например:--project save-walter-white-1234abcd
) - Установите опцию
--token
в секрет РепозиторияBENCHER_API_TOKEN
. Смотрите документацию--token
для более подробной информации. (например:--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Установите опцию
--branch
в имя ветки. Смотрите выбор ветки для полного обзора. (например:--branch main
) - Установите опцию
--testbed
в имя тестовой среды. Это должно, вероятно, совпадать с машиной, выбранной вruns-on
. Смотрите документацию--testbed
для более подробной информации. (например:--testbed ubuntu-latest
) - Установите опцию
--adapter
в желаемый адаптер инструмента для бенчмаркинга. Смотрите адаптеры инструментов для бенчмаркинга для полного обзора. (например:--adapter json
) - Установите флаг
--err
, чтобы команда завершалась с ошибкой, если сгенерировано предупреждение. Смотрите Пороги и Предупреждения для полного обзора. (например:--err
) - Укажите аргументы команды бенчмарка.
Смотрите команду бенчмарка для полного обзора.
(например:
bencher mock
)
Пулл Реквесты
Чтобы поймать регрессии производительности в пулл реквестах, вам нужно будет запускать бенчмарки на PRs.
Если вы ожидаете PRs только из веток в том же самом репозитории,
то вы можете просто создать другой рабочий процесс для запуска on
событий pull_request
из того же репозитория.
⚠️ Это решение работает только в том случае, если все PRs из одного и того же репозитория! Смотрите Пулл Реквесты из форков ниже.
-
Создайте файл
workflow
в GitHub Actions. (например:.github/workflows/pr_benchmarks.yml
) -
Запускать на событиях
pull_request
:opened
- Создан пулл реквест.reopened
- Повторно открыт ранее закрытый пулл реквест.edited
- Отредактировано название или содержание пулл реквеста или изменена базовая ветка пулл реквеста.synchronize
- Обновлена главная ветка пулл реквеста. Например, главная ветка обновлена из базовой ветки или были добавлены новые коммиты в главную ветку.
Смотрите документацию GitHub Actions
on
и документацию GitHub Actionspull_request
для полного обзора. (например:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Создайте
job
в GitHub Actions. (например:jobs: benchmark_pr_branch
) -
Запускать на событиях
pull_request
только в том случае, если пулл реквест из того же самого репозитория. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! Для работы с пулл реквестами из форков см. Пулл Реквесты из форков ниже. (например:if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
) -
Установите разрешения для
GITHUB_TOKEN
наwrite
дляpull-requests
. В зависимости от ваших настроек GitHub это может не требоваться. Но для всех организаций и личных репозиториев, созданных после 2 февраля 2023 года, это поведение по умолчанию. Смотрите документацию GitHub для полного обзора. (например:permissions: pull-requests: write
) -
Укажите тип машины, на которой будет выполняться работа. Смотрите документацию GitHub Actions
runs-on
для полного обзора. (например:runs-on: ubuntu-latest
) -
Скачайте исходный код ветки PR. (например:
uses: actions/checkout@v4
) -
Установите Bencher CLI, используя действие GitHub. (например:
uses: bencherdev/bencher@main
) -
Используйте подкоманду
bencher run
CLI для запуска бенчмарков вашего пулл реквеста. Смотрите подкоманду CLIbencher run
для полного обзора. (например:bencher run
) -
Установите опцию
--project
на slug проекта. Смотрите документацию--project
для более подробной информации. (например:--project save-walter-white-1234abcd
) -
Установите опцию
--token
на секрет репозиторияBENCHER_API_TOKEN
. Смотрите документацию--token
для более подробной информации. (например:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Установите опцию
--branch
на имя ветки PR, используя контекст GitHub Actionsgithub
. Смотрите выбор ветки для полного обзора. (например:--branch '${{ github.head_ref }}'
) -
Установите опцию
--branch-start-point
на исходную точку базовой ветки PR, используя контекст GitHub Actionsgithub
. Смотрите выбор ветки для полного обзора. (например:--branch-start-point '${{ github.base_ref }}'
) -
Установите опцию
--branch-start-point-hash
на хэш исходной точки базовой ветки PR, используя событие GitHub Actionspull_request
. Смотрите выбор ветки для полного обзора. (например:--branch-start-point-hash '${{ github.event.pull_request.base.sha }}'
) -
Установите флаг
--branch-reset
, чтобы всегда сбрасывать ветку до исходной точки. Это предотвратит дрейф данных измерений. Смотрите выбор ветки для полного обзора. (например:--branch-reset
) -
Установите опцию
--testbed
на имя Testbed. Это, вероятно, должно совпадать с машиной, выбранной вruns-on
. Смотрите документацию--tested
для более подробной информации. (например:--testbed ubuntu-latest
) -
Установите опцию
--adapter
на желаемый адаптер для выполнения бенчмарков. Смотрите адаптеры для выполнения бенчмарков для полного обзора. (например:--adapter json
) -
Установите флаг
--err
, чтобы команда завершалась неудачно, если будет создано предупреждение. Смотрите Пороги и предупреждения для полного обзора. (например:--err
) -
Установите опцию
--github-actions
на токен аутентификации API GitHub, чтобы публиковать результаты в виде комментария к пулл реквесту, используя переменную окруженияGITHUB_TOKEN
в GitHub Actions. Смотрите документацию--github-actions
для более подробной информации. (например:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
Укажите аргументы команды bенчмарка. Смотрите команду bенчмарка для полного обзора. (например:
bencher mock
)
Pull Request’ы из форков
Если вы планируете принимать pull request’ы из форков, как это часто бывает в публичных проектах с открытым исходным кодом, вам потребуется немного иначе подходить к вопросу.
Из соображений безопасности, такие секреты, как ваш BENCHER_API_TOKEN
и GITHUB_TOKEN
, недоступны в GitHub Actions для pull request’ов из форков. То есть, если внешний участник создает pull request из форка, приведенный выше пример не сработает.
Есть два варианта для 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 для полного обзора.
-
Создайте первый файл
workflow
для GitHub Actions. (например,.github/workflows/run_fork_pr_benchmarks.yml
) -
Назовите этот рабочий процесс, чтобы его можно было использовать во втором рабочем процессе. (например,
name: Запуск и кеширование сравнительного анализа
) -
Запускайте на
pull_request
событиях:opened
- Pull request был создан.reopened
- ранее закрытый pull request был снова открыт.edited
- Заголовок или содержимое pull request было отредактировано, либо базовая ветка pull request была изменена.synchronize
- Рабочая ветка pull request была обновлена. Например, рабочая ветка была обновлена от базовой ветки или в рабочую ветку были добавлены новые коммиты.
См. документацию GitHub Actions
on
и документацию GitHub Actionspull_request
для полного обзора. (например,on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Создайте задачу для GitHub Actions. (например,
jobs: benchmark_fork_pr_branch
) -
Установите тип машины, на которой будет выполняться задача. См. документацию GitHub Actions
runs-on
для полного обзора. (например,runs-on: ubuntu-latest
) -
Выполните checkout исходного кода ветки fork PR. (например,
uses: actions/checkout@v4
) -
Запустите ваши сравнительные тесты и сохраните результаты в файл. (например,
/bin/echo '{ ... }' > benchmark_results.json
) -
Загрузите файл с результатами сравнительного анализа как артефакт. (например,
uses: actions/upload-artifact@v4
) -
Загрузите объект события
pull_request
как артефакт. (например,uses: actions/upload-artifact@v4
)
- Создайте второй файл
workflow
для GitHub Actions. (например,.github/workflows/track_fork_pr_benchmarks.yml
) - Назовите этот второй рабочий процесс.
(например,
name: Отслеживание сравнительных анализов с помощью Bencher
) - Свяжите два рабочих процесса с помощью
события
workflow_run
. (например,on: workflow_run: ...
) - Создайте задачу для GitHub Actions.
(например,
jobs: track_fork_pr_branch
) - Запускайте эту задачу только если выполнение предыдущего рабочего процесса было успешным, используя
событие GitHub Actions
workflow_run
. (например,if: github.event.workflow_run.conclusion == 'success'
) - Установите тип машины, на которой будет выполняться задача.
См. документацию GitHub Actions
runs-on
для полного обзора. (например,runs-on: ubuntu-latest
) - Установите имена файлов с результатами сравнительного анализа и объектом события
pull_request
как переменные окружения. (например,env: ...
) - Загрузите кешированные результаты сравнительного анализа и событие
pull_request
. (например,uses: actions/github-script@v6
) - Распакуйте кешированные результаты сравнительного анализа и событие
pull_request
. (например,unzip ...
) - Экспортируйте необходимые данные из события
pull_request
как переменные окружения. (например,core.exportVariable(...)
) - Установите Bencher CLI, используя GitHub Action.
(например,
uses: bencherdev/bencher@main
) - Используйте подкоманду
bencher run
CLI для отслеживания ваших бенчмарков из ветки fork pull request. См. подкомандуbencher run
CLI для полного обзора. (например,bencher run
) - Установите опцию
--project
на slug проекта. См. документацию по опции--project
для более подробной информации. (например,--project save-walter-white-1234abcd
) - Установите опцию
--token
на секрет RepositoryBENCHER_API_TOKEN
. См. документацию по опции--token
для более подробной информации. (например,--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Установите опцию
--branch
на отформатированный номер fork PR, используя событие GitHub Actionspull_request
. См. выбор ветки для полного обзора. (например,--branch '${{ env.PR_HEAD }}'
) - Установите опцию
--branch-start-point
на начальную точку базовой ветки fork PR, используя событие GitHub Actionspull_request
. См. выбор ветки для полного обзора. (например,--branch-start-point '${{ env.PR_BASE }}'
) - Установите опцию
--branch-start-point-hash
на хэш начальной точки базовой ветки fork PR, используя событие GitHub Actionspull_request
. См. выбор ветки для полного обзора. (например,--branch-start-point-hash '${{ env.PR_BASE_SHA }}'
) - Установите флаг
--branch-reset
, чтобы всегда сбрасывать ветку до начальной точки. Это предотвратит дрейф данных бенчмарков. См. выбор ветки для полного обзора. (например,--branch-reset
) - Установите опцию
--testbed
на имя тестовой машины. Это должно соответствовать выбранной машине вruns-on
. См. документацию по опции--tested
для более подробной информации. (например,--testbed ubuntu-latest
) - Установите опцию
--adapter
на нужный адаптер сравнительного анализа. См. адаптеры сравнительного анализа для полного обзора. (например,--adapter json
) - Установите флаг
--err
, чтобы команда завершалась неудачей, если сгенерировано предупреждение. См. Пороги и Предупреждения для полного обзора. (например,--err
) - Установите опцию
--github-actions
на токен аутентификации GitHub API, чтобы опубликовать результаты в виде комментария к pull request, используя переменную окруженияGITHUB_TOKEN
GitHub Actions. См. документацию по опции--github-actions
для более подробной информации. (например,--github-actions '${{ secrets.GITHUB_TOKEN }}'
) - Установите опцию
--ci-number
на номер pull request. См. документацию по опции--ci-number
для более подробной информации. (например,--ci-number '${{ env.PR_NUMBER }}'
) - Установите опцию
--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
.
-
Создайте файл
workflow
в GitHub Actions. (например:.github/workflows/pr_target_benchmarks.yml
) -
Запускайте на события
pull_request
:opened
- был создан pull request.reopened
- ранее закрытый pull request был вновь открыт.edited
- заголовок или основная часть pull request были отредактированы, или базовая ветка pull request была изменена.synchronize
- головная ветка pull request была обновлена. Например, головная ветка была обновлена из базовой или в головную ветку были добавлены новые коммиты.
Полный обзор см. в документации GitHub Actions
on
и документации GitHub Actionspull_request
. (например:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Создайте первую
job
GitHub Actions, чтобы проверить, требуется ли рецензия. (например:jobs: fork_pr_requires_review
) -
Установите
environment
наinternal
, если и только если pull request из того же репозитория. В противном случае установитеenvironment
наexternal
, что потребует одобрения рецензента для продолжения. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! (например:environment: ${{ (github.event.pull_request.head.repo.full_name == github.repository && 'internal') || 'external' }}
) -
Создайте вторую
job
GitHub Actions для запуска ваших бенчмарков. (например:benchmark_fork_pr_branch
) -
Сделайте
job benchmark_fork_pr_branch
зависимой отjob fork_pr_requires_review
. ⚠️ НЕ УДАЛЯЙТЕ ЭТУ СТРОКУ! Полный обзор см. в документации GitHub Actionsneeds
. (например:needs: fork_pr_requires_review
) -
Установите тип машины, на которой будет выполняться задача. Полный обзор см. в документации GitHub Actions
runs-on
. (например:runs-on: ubuntu-latest
) -
Выполните 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
)
- Укажите репозиторий fork PR (например:
-
Установите Bencher CLI, используя GitHub Action. (например:
uses: bencherdev/bencher@main
) -
Используйте подкоманду CLI
bencher run
для запуска бенчмарков вашей ветки fork PR. Полный обзор см. в подкомандеbencher run
CLI. (например:bencher run
) -
Установите параметр
--project
на слаг проекта. Подробности см. в документации--project
. (например:--project save-walter-white-1234abcd
) -
Установите параметр
--token
на секретBENCHER_API_TOKEN
репозитория. Подробности см. в документации--token
. (например:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Установите параметр
--branch
на отформатированный номер fork PR, используя событиеpull_request
в GitHub Actions. Полный обзор см. в выбор ветки. (например:--branch '${{ github.event.number }}/merge'
) -
Установите параметр
--branch-start-point
на начальную точку базовой ветки fork PR, используя контекстgithub
в GitHub Actions. Полный обзор см. в выбор ветки. (например:--branch-start-point '${{ github.base_ref }}'
) -
Установите параметр
--branch-start-point-hash
на хэш начальной точки базовой ветки fork PR, используя событиеpull_request
в GitHub Actions. Полный обзор см. в выбор ветки. (например:--branch-start-point-hash '${{ github.event.pull_request.base.sha }}'
) -
Установите флаг
--branch-reset
для всегда сброса ветки к начальной точке. Это предотвратит дрейф данных бенчмарков. Полный обзор см. в выбор ветки. (например:--branch-reset
) -
Установите параметр
--testbed
на название тестовой среды. Это, вероятно, должно совпадать с машиной, выбранной вruns-on
. Подробности см. в документации--testbed
. (например:--testbed ubuntu-latest
) -
Установите параметр
--adapter
на желаемый адаптер для бенчмарк-харнессов. Полный обзор см. в адаптерах бенчмарк-харнессов. (например:--adapter json
) -
Установите флаг
--err
, чтобы команда завершалась с ошибкой при генерации предупреждения. Полный обзор см. в порогах и предупреждениях. (например:--err
) -
Установите параметр
--github-actions
на токен аутентификации API GitHub для публикации результатов в виде комментария к Pull Request, используя переменную средыGITHUB_TOKEN
в GitHub Actions. Подробности см. в документации--github-actions
. (например:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
Укажите параметры команды бенчмарк. Полный обзор см. в команда бенчмарк. (например:
bencher mock
)
🐰 Поздравляем! Вы научились использовать Bencher в GitHub Actions! 🎉