Подкоманда bencher run CLI
bencher run - самая популярная подкоманда CLI.
Она используется для запуска тестов производительности и отчетов о результатах.
Таким образом, она является одной из самых сложных подкоманд.
На этой странице будет рассказано о параметрах, флагах и аргументах, которые можно передать bencher run.
bencher run [OPTIONS] [COMMAND] [ARGUMENTS...]Команда для бенчмаркинга
Первым аргументом для bencher run является необязательная команда бенчмаркинга.
Это команда, которая будет выполнена для вызова вашего механизма бенчмаркинга.
Также её можно задать с помощью переменной окружения BENCHER_CMD.
По умолчанию эта команда выполняется в оболочке,
которую можно настроить с помощью опций --shell и --flag.
Её вывод анализируется адаптером механизма бенчмаркинга,
который можно задать с помощью опции --adapter.
Однако, если механизм бенчмаркинга выводит результаты в файл, то должна быть также использована опция --file,
чтобы указать путь к файлу вывода.
В качестве альтернативы для отслеживания размера файла вывода (например, размера бинарного файла) вместо его содержимого,
можно использовать опцию --file-size, чтобы указать путь к файлу вывода.
Если вы предпочитаете не выполнять команду в оболочке, вы можете использовать флаг --exec или просто предоставить дополнительные аргументы к вашей команде как дополнительные аргументы к bencher run.
Форма Shell:
bencher run "bencher mock"Форма Exec:
bencher run bencher mockКоманду для бенчмаркинга можно выполнить несколько раз, используя опцию --iter,
и эти результаты можно объединить в один результат с помощью опции --fold.
Если какая-либо из итераций не удастся, то вся команда считается неудачной,
если только не установлен флаг --allow-failure.
Если команда для бенчмаркинга не указана, но указана опция --file,
то bencher run просто будет читать из пути файла вывода.
Аналогичным образом, если команда для бенчмаркинга не указана, но указана опция --file-size,
то bencher run будет читать размер файла по указанному пути файла.
Если не указана команда для бенчмаркинга, опция --file,
ни опция --file-size,
то bencher run будет читать из stdin.
Это позволяет вам сохранить вывод другой команды в файл или перенаправить его в bencher run.
Options
--project <PROJECT>
Необязательно: Либо параметр --project, либо переменная окружения BENCHER_PROJECT может быть установлена в слаг или UUID для проекта. Если указано значение в виде слага и проект еще не существует, он будет создан для вас. Однако, если указано значение в виде UUID, тогда проект должен уже существовать. Если оба указаны, параметр --project имеет приоритет над переменной окружения BENCHER_PROJECT. Если ни один из них не указан, для вас будет создан слаг проекта на основе:
- Названия родительского каталога для репозитория
git, если оно доступно. - Короткого хеша из 7 шестнадцатеричных символов для начального коммита репозитория
git, если он доступен. - Пальцевого отпечатка из 13 буквенно-цифровых символов локальной машины для поддерживаемых операционных систем.
Например, сгенерированный слаг проекта может выглядеть как: project-abc4567-wxyz123456789
Когда для вас создается новый проект, независимо от того, указан слаг или он сгенерирован, проект должен принадлежать к организации. Если пользователь аутентифицирован, проект добавляется в персональную организацию этого пользователя. Если пользователь не аутентифицирован, проект будет создан в новой unclaimed организации. Эта организация может быть claimed со публичной страницы производительности проекта или с использованием слага проекта при аутентифицированном последующем запуске команды bencher run.
--token <TOKEN>
Необязательно: Либо опция --token, либо переменная окружения BENCHER_API_TOKEN может быть установлена в действительный API токен.
Если оба заданы, опция --token имеет приоритет над переменной окружения BENCHER_API_TOKEN.
Если ни один не задан, то проект должен быть незаявленным.
То есть, если вы уже заявили проект, вы должны предоставить действительный API токен.
Нажмите здесь, чтобы создать API токен.
--branch <BRANCH>
--hash <HASH>
--start-point <BRANCH>
--start-point-hash <HASH>
--start-point-max-versions <COUNT>
--start-point-clone-thresholds
--start-point-reset
См. Выбор ветки для полного обзора.
--testbed <TESTBED>
Необязательно: Либо опция --testbed, либо переменная окружения BENCHER_TESTBED могут быть установлены в имя, слаг или UUID для Тестового стенда.
Если указанное значение — имя или слаг, и Тестовый стенд еще не существует, он будет создан для вас.
Однако, если указанное значение — UUID, то Тестовый стенд должен уже существовать.
Если указаны оба варианта, опция --testbed имеет приоритет над переменной окружения BENCHER_TESTBED.
Если ни один из них не указан, то используются Linux, macOS или Windows,
в зависимости от операционной системы хоста.
Если bencher CLI был скомпилирован для другой операционной системы,
тогда по умолчанию используется localhost в качестве Тестового стенда.
--threshold-measure <MEASURE>
--threshold-test <TEST>
--threshold-min-sample-size <SAMPLE_SIZE>
--threshold-max-sample-size <SAMPLE_SIZE>
--threshold-window <WINDOW>
--threshold-lower-boundary <BOUNDARY>
--threshold-upper-boundary <BOUNDARY>
--thresholds-reset
--err
Смотрите пороги и оповещения для полного обзора.
--adapter <ADAPTER>
--average <AVERAGE>
--file <FILE>
--build-time
--file-size <FILE>
Смотрите адаптеры оснастки для тестирования для полного обзора.
--iter <COUNT>
Опционально: Число повторений тестирования. По умолчанию 1.
--fold <AGGREGATE_FUNCTION>
Опционально: Возможность объединения нескольких результатов в один.
Требует: установки --iter.
Возможные значения:
min: Минимальное значениеmax: Максимальное значениеmean: Среднее значениеmedian: Медианное значение
--backdate <SECONDS>
Опционально: Возможность отката даты отчета (секунды со времени эпохи). Внимание: Это не повлияет на порядок предыдущих отчетов! Это полезно при начальном занесении исторических данных в проект в хронологическом порядке.
--allow-failure
Опционально: Разрешить сбой теста производительности.
--format <FORMAT>
Необязательно: Формат итогового отчета.
По умолчанию используется human.
Возможные значения:
human: Человеко-читаемый форматjson: Формат JSONhtml: Формат HTML
--quiet
Необязательно: Тихий режим, выводится только окончательный отчет.
Используйте опцию --format, чтобы изменить формат вывода.
--github-actions <GITHUB_TOKEN>
Необязательно: Установите токен аутентификации API GitHub. Самый удобный способ сделать это - использовать переменную окружения GITHUB_TOKEN в GitHub Actions (например, --github-actions ${{ secrets.GITHUB_TOKEN }}). Когда эта опция установлена и bencher run используется в GitHub Actions как часть запроса на вытягивание, результаты будут добавлены в запрос как комментарий. Это требует, чтобы у токена были полномочия pull-requests с разрешениями на write. В противном случае результаты будут добавлены к коммиту как проверка GitHub. Это требует, чтобы у токена были полномочия checks с разрешениями на write. В любом случае, результаты также будут добавлены в сводку задания.
🐰 Если вы запускаете внутри контейнера Docker в GitHub Action, вам нужно будет передать следующие переменные окружения и смонтировать путь, указанный в
GITHUB_EVENT_PATH:
GITHUB_ACTIONSGITHUB_EVENT_NAMEGITHUB_EVENT_PATHGITHUB_SHAGITHUB_API_URL(GitHub Enterprise Server только)
--ci-only-thresholds
Опционально: отправлять результаты в CI только если существует пороговое значение для ветки, тестовой среды и меры.
Если пороговые значения отсутствуют, ничего отправляться не будет.
Требуется: --github-actions
--ci-only-on-alert
Опционально: начинается публикация результатов в CI только если сгенерировано предупреждение.
Если предупреждение сгенерировано, все последующие результаты также будут опубликованы, даже если они не содержат предупреждений.
Требуется: --github-actions
--ci-id <ID>
Необязательно: Пользовательский идентификатор для отправки результатов в CI. По умолчанию Bencher автоматически сегментирует результаты по комбинации: Проект, Ветка, Тестовая среда и Адаптер. Установка пользовательского идентификатора полезна, когда Bencher запускается несколько раз в том же CI-потоке для той же комбинации Проекта, Ветки, Тестовой среды и Адаптера. Требуется: --github-actions
--ci-number <NUMBER>
Необязательно: номер задачи для отправки результатов на CI.
Bencher постарается определить номер задачи CI, необходимый для отправки результатов.
Однако это не всегда доступно в сложных настройках, таких как использование workflow_run в GitHub Actions.
Требуется: --github-actions
--shell <SHELL>
Необязательный: Путь к командному интерпретатору.
По умолчанию /bin/sh в UNIX-подобных средах и cmd в Windows.
--flag <FLAG>
Опционально: флаг команды оболочки.
По умолчанию: -c в Unix-подобных средах и /C в Windows.
--exec
Необязательно: Запускать команду как исполняемый файл, а не как команду оболочки.
По умолчанию, если количество аргументов для bencher run больше одного.
--host <URL>
Опционально: URL-адрес сервера бэкенда. По умолчанию используется Bench Cloud: https://api.bencher.dev
--insecure-host
Опционально: Разрешить небезопасное подключение к серверу Bencher API.
Этот флаг полезен, когда вы подключаетесь к локальной установке Bencher с самозаверяющим сертификатом или сертификатом, который не включен в хранилище сертификатов системы. Это применимо только к HTTPS-соединениям, так как HTTP-соединения изначально небезопасны.
ПРЕДУПРЕЖДЕНИЕ: Используйте --insecure-host только в безопасной сети с проверенными источниками, так как это обходит проверку SSL и может подвергнуть вас атакам типа “человек посередине”.
--native-tls
Необязательно: Загрузка TLS сертификатов из локального хранилища сертификатов платформы.
По умолчанию, bencher загружает сертификаты из встроенного webpki-roots крейта.
webpki-roots представляют собой надежный набор доверенных корней от Mozilla,
и их включение в bencher улучшает портативность и производительность.
Это особенно актуально для macOS, где чтение системного хранилища доверия вызывает значительную задержку.
Однако в некоторых случаях, возможно, вы захотите использовать локальное хранилище сертификатов платформы, особенно если вы полагаетесь на корпоративный доверенный корень, включенный в системное хранилище сертификатов для обязательного прокси или самоподписанных Bencher Self-Hosted соединений.
--timeout <SECONDS>
Опционально: тайм-аут запроса в секундах. По умолчанию 15 секунд.
--attempts <COUNT>
Необязательно: Максимальное количество попыток повторного запроса.
По умолчанию 10 попыток.
--retry-after <SECONDS>
Необязательно: начальное количество секунд ожидания между попытками (экспоненциальная задержка).
По умолчанию 1 секунда.
--dry-run
Опционально: Выполнить пробный запуск. Это не сохранит никаких данных в бекенд. Ни Отчет, ни Ветвь (как описано в выбор ветви), ни Тестовая среда не будут созданы.
--help
Необязательно: Вывести справку.
🐰 Поздравляем! Вы изучили основы
bencher run! 🎉