Как использовать 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
    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. Установите тип машины, на которой будет выполняться задание. См. документацию о runs-on для GitHub Actions для получения подробной информации. (например, runs-on: ubuntu-latest)
  5. Получите исходный код вашей основной ветки. (например, uses: actions/checkout@v4)
  6. Установите Bencher CLI, используя GitHub Action. (например, uses: bencherdev/bencher@main)
  7. Используйте подкaманды CLI bencher run для запуска бенчмарков вашей ветки main. См. подкaманды CLI bencher run для получения полной информации. (например, bencher run)
  8. Установите опцию --project на шифр проекта. См. документацию о --project для получения более подробной информации. (например, --project save-walter-white-1234abcd)
  9. Установите опцию --token на секрет Repositorий BENCHER_API_TOKEN. См. документацию о --token для получения более подробной информации. (например, --token '${{ secrets.BENCHER_API_TOKEN }}')
  10. Установите опцию --branch на имя основной ветки. См. документацию о --branch для получения полной информации. (например, --branch main)
  11. Установите опцию --testbed на имя Testbed. Это, вероятно, должно соответствовать машине, выбранной в runs-on. См. документацию о --tested для получения более подробной информации. (например, --testbed ubuntu-latest)
  12. Установите порог для ветки 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)
  13. Установите флаг --err, чтобы команда завершалась с ошибкой, если будет сформировано оповещение. См. документацию о --err для получения полной информации. (например, --err)
  14. Установите опцию --adapter на формат метрик Bencher в формате JSON (json), который сгенерирован bencher mock. См. Адаптеры для бенчмарк-харнесов для получения полной информации. (например, --adapter json)
  15. Установите опцию --github-actions на токен аутентификации API GitHub, чтобы отправить результаты в виде комментария GitHub Checks, используя переменную окружения GITHUB_TOKEN для GitHub Actions. См. документацию о --github-actions для получения более подробной информации. (например, --github-actions '${{ secrets.GITHUB_TOKEN }}')
  16. Укажите аргументы для команды бенчмарков. См. документацию о команде бенчмарков для получения полной информации. (например, bencher mock)

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

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

⚠️ Это решение работает только если все PR из того же репозитория! См. [Запросы на вытягивание из форков][pull requests from forks] ниже.

.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 - Создан запрос на вытягивание.
    • reopened - Ранее закрытый запрос на вытягивание был снова открыт.
    • edited - Название или тело запроса на вытягивание изменено, или базовая ветка запроса изменена.
    • synchronize - Голова ветки запроса на вытягивание обновлена. Например, голова ветки обновлена от базовой ветки или в голову ветки добавлены новые коммиты.

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

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

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

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

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

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

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

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

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

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

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

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

    1. Установите опцию --start-point для начальной точки ветки PR с использованием [контекста github в GitHub Actions][github actions context]. См. [документацию --start-point][start point] для полного обзора. (пример: --start-point '${{ github.base_ref }}')
    2. Установите опцию --start-point-hash для хеша git начальной точки ветки PR с использованием [события pull_request в GitHub Actions][github action pull_request]. См. [документацию --start-point-hash][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] для полного обзора. (пример: --start-point-clone-thresholds)
    4. Установите флаг --start-point-reset для постоянного сброса ветки PR к начальной точке. Это предотвратит дрейф данных бенчмарка. См. [документацию --start-point-reset][start point reset] для полного обзора. (пример: --start-point-reset)

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

  15. Установите флаг --err для провала команды, если сгенерировано предупреждение. См. [документацию --err][alert err] для полного обзора. (пример: --err)

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

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

  18. Укажите аргументы команды для бенчмарка. См. [документацию команды для бенчмарка][command argument] для полного обзора. (пример: bencher mock)

Чтобы очистить ветку PR после закрытия запроса на слияние, вы можете создать отдельный workflow, который будет запускаться по событиям типа closed для pull_request. Этот 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
    permissions:
      pull-requests: write
    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 PRs см. Запросы на слияние из форков ниже. (например, 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. Установите тип машины, на которой будет выполняться работа. Ознакомьтесь с документацией 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 archive CLI, чтобы архивировать ветку PR. (например, bencher archive)

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

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

  12. Установите опцию --branch на имя ветки PR используя контекст github GitHub Actions. (например, --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.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 }}' \
          --start-point '${{ env.PR_BASE }}' \
          --start-point-hash '${{ env.PR_BASE_SHA }}' \
          --start-point-clone-thresholds \
          --start-point-reset \
          --testbed ubuntu-latest \
          --err \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          --ci-number '${{ env.PR_NUMBER }}' \
          --file "$BENCHMARK_RESULTS"
  1. Создайте первый файл workflow для GitHub Actions. (например: .github/workflows/fork_pr_benchmarks_track.yml)
  2. Назовите этот рабочий процесс вторым рабочим процессом. (например: name: Track Benchmarks with Bencher)
  3. Свяжите два рабочих процесса с использованием события workflow_run. (например: on: workflow_run: ...)
  4. Создайте job для GitHub Actions. (например: jobs: track_fork_pr_branch)
  5. Выполните этот job только в случае успешного завершения предыдущего рабочего процесса, используя событие workflow_run GitHub Actions. (например: if: github.event.workflow_run.conclusion == 'success')
  6. Установите тип машины, на которой будет выполняться job. См. документацию по runs-on GitHub Actions для полного обзора. (например: runs-on: ubuntu-latest)
  7. Установите результаты тестирования и объектное событие pull_request в качестве переменных среды. (например: env: ...)
  8. Загрузите кэшированные результаты тестирования и события pull_request, используя действие action-download-artifact GitHub. (например: uses: dawidd6/action-download-artifact@v6)
  9. Экспортируйте необходимые данные из события pull_request как переменные среды. (например: core.exportVariable(...))
  10. Установите Bencher CLI, используя действие GitHub. (например: uses: bencherdev/bencher@main)
  11. Используйте подкоманду CLI bencher run для отслеживания тестов вашей ветки-форка pull request. См. подкоманду CLI bencher run для полного обзора. (например: bencher run)
  12. Установите параметр --project в значение Project slug. См. документацию по --project для получения более подробной информации. (например: --project save-walter-white-1234abcd)
  13. Установите опцию --token в секрет репозитория BENCHER_API_TOKEN. См. документацию по --token для получения более подробной информации. (например: --token '${{ secrets.BENCHER_API_TOKEN }}')
  14. Установите параметр --branch в имя ветки форка PR , используя [контекст github GitHub Actions][github actions context]. См. документацию по --branch для полного обзора. (например: --branch '${{ env.PR_HEAD }}')
  15. Установите начальную точку для ветки форка PR:
    1. Установите параметр --start-point в начальную точку ветки форка PR , используя [контекст github GitHub Actions][github actions context]. См. документацию по --start-point для полного обзора. (например: --start-point '${{ env.PR_BASE }}')
    2. Установите параметр --start-point-hash в хеш git начальной точки ветки форка PR , используя событие pull_request GitHub Actions. См. документацию по --start-point-hash для полного обзора. (например: --start-point-hash '${{ env.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 в имя 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 в токен аутентификации API GitHub для публикации результатов в виде комментария в Pull Request, используя переменную окружения GITHUB_TOKEN GitHub Actions. См. документацию по --github-actions для получения более подробной информации. (например: --github-actions '${{ secrets.GITHUB_TOKEN }}')
  20. Установите параметр --ci-number в номер pull request. См. документацию по --ci-number для получения более подробной информации. (например: --ci-number '${{ env.PR_NUMBER }}')
  21. Установите параметр --file в путь к файлу с результатами тестирования. См. команду benchmark для полного обзора. (например: --file "$BENCHMARK_RESULTS")

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

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


jobs:
  archive_fork_pr_branch:
    name: Archive closed fork PR branch with Bencher
    permissions:
      pull-requests: write
    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:

    • closed - Запрос на слияние был закрыт.

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

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

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

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

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

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

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

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

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

  11. Установите параметр --branch на имя ветки PR используя контекст github в 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: Sat, October 12, 2024 at 12:40:00 PM UTC