Как использовать Bencher в GitLab CI/CD

В зависимости от вашего варианта использования, вы можете настроить Непрерывное Бенчмарк-тестирование в GitLab CI/CD для:

• Целевой ветки
• Запросов на слияние

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

Целевая Ветка

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

benchmark_target_branch:
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE == "push"
      when: always
  image: debian:bullseye
  before_script:
    - curl --proto '=https' --tlsv1.2 -sSfL https://bencher.dev/download/install-cli.sh | sh
  script:
    - |
      bencher run \
      --project project-abc4567-wxyz123456789 \
      --token "$BENCHER_API_TOKEN" \
      --branch main \
      --testbed debian:bullseye \
      --threshold-measure latency \
      --threshold-test t_test \
      --threshold-max-sample-size 64 \
      --threshold-upper-boundary 0.99 \
      --thresholds-reset \
      --err \
      --adapter json \
      bencher mock

1. Создайте файл GitLab CI/CD. (например, .gitlab-ci.yml)
2. Создайте задачу GitLab CI/CD. (например, benchmark_target_branch)
3. Запускайте if, если конвейер был вызван push в main ветку. Ознакомьтесь с документацией GitLab CI/CD rules и предопределённые переменные GitLab CI/CD для полного обзора. (например, rules: if: ...)
4. Установите image, в котором будет выполнена задача. Ознакомьтесь с документацией GitLab CI/CD image для полного обзора. (например, image: debian:bullseye)
5. Установите Bencher CLI с помощью скрипта установки. (например, before_script: ...)
6. Используйте подкоманду CLI bencher run, чтобы запустить бенчмарки вашей main ветки. Ознакомьтесь с подкомандой bencher run CLI для полного обзора. (например, bencher run)
7. Установите опцию --project на слаг проекта. Смотрите документацию --project для получения подробной информации. (например, --project project-abc4567-wxyz123456789)
8. Установите опцию --token на маскированную переменную окружения BENCHER_API_TOKEN. Смотрите документацию --token для получения подробной информации. (например, --token "$BENCHER_API_TOKEN")
9. Установите опцию --branch на имя ветки. Смотрите документацию --branch для полного обзора. (например, --branch main)
10. Установите опцию --testbed на имя тестовога стенда. Это, вероятно, должно совпадать с машиной, выбранной в image. Смотрите документацию --testbed для получения подробной информации. (например, --testbed debian:bullseye)
11. Установите пороговое значение для main ветки, тестового стенда debian:bullseye и метрики latency:
    1. Установите опцию --threshold-measure на встроенную метрику latency, сгенерированную bencher mock. Смотрите документацию --threshold-measure для получения подробной информации. (например, --threshold-measure latency)
    2. Установите опцию --threshold-test на критерий Стьюдента (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)
12. Установите флаг --err, чтобы команда завершалась с ошибкой, если создаётся предупреждение. Смотрите документацию --err для полного обзора. (например, --err)
13. Установите опцию --adapter на Bencher Metric Format JSON (json), который генерируется bencher mock. Смотрите адаптеры тестового стенда для полного обзора. (например, --adapter json)
14. Укажите аргументы команды бенчмарка. Смотрите документацию команды бенчмарк для полного обзора. (например, bencher mock)

Запросы на слияние

Чтобы определить регрессию производительности в запросах на слияние, вам нужно запускать ваши тесты производительности на этих запросах. Ниже приведенный пример следует использовать только для веток в рамках того же репозитория.

benchmark_mr_branch:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: always
  image: debian:bullseye
  before_script:
    - curl --proto '=https' --tlsv1.2 -sSfL https://bencher.dev/download/install-cli.sh | sh
  script:
    - |
      bencher run \
      --project project-abc4567-wxyz123456789 \
      --token "$BENCHER_API_TOKEN" \
      --branch "$CI_COMMIT_REF_NAME" \
      --start-point "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" \
      --start-point-hash "$CI_MERGE_REQUEST_TARGET_BRANCH_SHA" \
      --start-point-clone-thresholds \
      --start-point-reset \
      --testbed debian:bullseye \
      --err \
      --adapter json \
      bencher mock

1. Обновите файл GitLab CI/CD. (например, .gitlab-ci.yml)
2. Создайте задачу GitLab CI/CD. (например, benchmark_mr_branch)
3. Выполните if, если конвейер был запущен событием merge_request_event. Просмотрите документацию по правилам GitLab CI/CD и документацию по предопределенным переменным GitLab CI/CD для полного обзора. (например, rules: if: ...)
4. Установите image, в котором будет выполняться задача. Просмотрите документацию по image GitLab CI/CD для полного обзора. (например, image: debian:bullseye)
5. Установите Bencher CLI с помощью удобного скрипта. (например, before_script: ...)
6. Используйте подкоманду bencher run CLI для запуска тестов производительности ветки запроса на слияние. Просмотрите подкоманду bencher run CLI для полного обзора. (например, bencher run)
7. Установите опцию --project на слаг проекта. Просмотрите документацию по --project для более подробной информации. (например, --project project-abc4567-wxyz123456789)
8. Установите опцию --token на замаскированную переменную среды BENCHER_API_TOKEN. Просмотрите документацию по --token для более подробной информации. (например, --token "$BENCHER_API_TOKEN")
9. Установите опцию --branch на имя ветки запроса на слияние, используя предопределенную переменную GitLab CI/CD. Просмотрите документацию по --branch для полного обзора. (например, --branch "$CI_COMMIT_REF_NAME")
10. Установите начальную точку для ветки запроса на слияние:
    1. Установите опцию --start-point на начальную точку ветки запроса на слияние, используя предопределенную переменную GitLab CI/CD. Просмотрите документацию по --start-point для полного обзора. (например, --start-point "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME")
    2. Установите опцию --start-point-hash на hash начальной точки ветки запроса на слияние git, используя предопределенную переменную GitLab CI/CD. Просмотрите документацию по --start-point-hash для полного обзора. (например, --start-point-hash "$CI_MERGE_REQUEST_TARGET_BRANCH_SHA")
    3. Установите флаг --start-point-clone-thresholds для клонирования порогов из начальной точки. Просмотрите документацию по --start-point-clone-thresholds для полного обзора. (например, --start-point-clone-thresholds)
    4. Установите флаг --start-point-reset для постоянного сброса ветки запроса на слияние на начальную точку. Это предотвратит искажение данных тестов производительности. Просмотрите документацию по --start-point-reset для полного обзора. (например, --start-point-reset)
11. Установите опцию --testbed на имя тестовой среды. Это должно вероятно соответствовать выбранной машине в image. Просмотрите документацию по --testbed для более подробной информации. (например, --testbed debian:bullseye)
12. Установите флаг --err для вызова ошибки команды, если будет сгенерировано предупреждение. Просмотрите документацию по --err для полного обзора. (например, --err)
13. Установите опцию --adapter на формат метрик Bencher JSON (json), который генерируется bencher mock. Просмотрите адаптеры тестировочных каркасов для полного обзора. (например, --adapter json)
14. Укажите аргументы команды бенчмаркинга. Просмотрите команду бенчмаркинга для полного обзора. (например, bencher mock)

Чтобы очистить ветку MR после закрытия его MR, вы можете создать отдельную задачу, которая будет запрашивать состояние MR с помощью API GitLab. Если состояние closed, эта задача заархивирует ветку MR с помощью команды bencher archive.

archive_mr_branch:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: always
  image: debian:bullseye
  before_script:
    - curl --proto '=https' --tlsv1.2 -sSfL https://bencher.dev/download/install-cli.sh | sh
    - |
      MR_STATE=$(curl --header "PRIVATE-TOKEN: $CI_JOB_TOKEN" "https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID" | jq -r .state)
      echo "Merge request state: $MR_STATE"
  script:
    - |
      if [ "$MR_STATE" = "closed" ]; then
        bencher archive \
        --project project-abc4567-wxyz123456789 \
        --token "$BENCHER_API_TOKEN" \
        --branch "$CI_COMMIT_REF_NAME"
      else
        echo 'Merge request is not `closed`. Skipping archival.'
      fi

1. Обновите файл GitLab CI/CD. (например: .gitlab-ci.yml)
2. Создайте задачу GitLab CI/CD. (например: archive_mr_branch)
3. Выполните if, если конвейер был вызван событием merge_request_event. Смотрите документацию по rules в GitLab CI/CD и документацию по предопределенным переменным в GitLab CI/CD для полного обзора. (например: rules: if: ...)
4. Установите image, в котором будет выполняться задача. Смотрите документацию по image в GitLab CI/CD для полного обзора. (например: image: debian:bullseye)
5. Установите Bencher CLI, используя удобный скрипт. (например: before_script: curl ...)
6. Проверьте состояние MR, используя API GitLab. (например: before_script: MR_STATE=$(...))
7. Используйте подкоманду CLI bencher archive для архивирования ветки MR, если состояние MR closed. (например: bencher archive)
8. Установите опцию --project для идентификатора проекта. Смотрите документацию по --project для получения более подробной информации. (например: --project project-abc4567-wxyz123456789)
9. Установите опцию --token для скрытой переменной окружения BENCHER_API_TOKEN. Смотрите документацию по --token для получения более подробной информации. (например: --token "$BENCHER_API_TOKEN")
10. Установите опцию --branch на имя ветки MR с использованием предопределенной переменной в GitLab CI/CD. (например: --branch "$CI_COMMIT_REF_NAME")

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

Продолжайте: Обзор сравнительного тестирования ➡