Конфигурация каждого теста должна лежать в отдельной папке. Имя конфигурационного файла должно соответствовать маске test-config*.yaml
.
Примеры описанных тестов можно посмотреть тут.
В папку с файлами конфигурации можно добавить следующие файлы:
- В файле
meta.json
можно описать свойства теста (все поля опциональны):# имя теста name: str # описание теста description: str # лейблы теста labels: {"test-label": "value"} # лейблы агентов, на которых тест нужно запускать agent_labels: {"agent-label": "value"} # количество агентов на каждый файл с конфигурацией multi: 1 # массив с описанием откуда брать внешние файлы (вне репозитория) external_data: [{"name": "", "s3bucket": "", "s3file": ""}]
- В файле
check_summary.sh
можно написать валидациюyc loadtesting test get $test_id
- В файле
check_report.sh
можно написать валидациюyc loadtesting test get-report-tables $test_id
Некоторые настройки теста можно определить в файле meta.json
.
-
имя теста:
{ "name": "smoke" }
-
описание теста:
{ "description": "If this test fails... ALARM!!!!!!!!!" }
-
метки теста:
{ "labels": { "k1": "v1", "k2": "v2" } }
-
требования к агенту, через спецификацию меток, которые должны быть у него проставлены:
{ "agent_labels": { "net": "1gb", "disk": "ssd" } }
Так как, в общем случае, скачивание агентом файлов напрямую из репозитория невозможно, необходимо использовать промежуточное хранилище, к которому будет доступ и у агента, и у CI. В качестве такого промежуточного хранилища предлагается использовать Object Storage.
При указании имени бакета через переменную среды YC_LT_DATA_BUCKET
:
- все дополнительные файлы в папке с тестом загружаются в бакет
YC_LT_DATA_BUCKET
(т.е. все файлы, кроме служебныхmeta.json
,config*.yaml
и т.д.) - для передачи списка необходимых файлов агенту, информация о них добавляется в запрос на создание теста
- по завершении теста, загруженные на первом шаге файлы удаляются из бакета
WARNING: У сервисного аккаунта, с которым запускается агент, должны быть права на чтение файлов из этого бакета.
WARNING2: У сервисного аккаунта, от лица которого создаются тесты, должны быть права на загрузку файлов в этот бакет.
Данный способ подходит в тех случаях, когда вы планируете использовать тестовые данные, которые изначально хранятся в Object Storage
В файле meta.json
можно описать секцию external_data
, в которой должно быть определен список из структур, определяющих имя бакета, имя файла в бакете, и имя, которое агент даст файлу при скачивании.
WARNING: У сервисного аккаунта, с которым запускается агент, должны быть права на чтение файлов из указанных бакетов.
Пример:
{
"external_data": [
{
"s3bucket": "loadtesting-data",
"s3file": "folder/user-data.json",
"name": "data.json"
},
{
"s3bucket": "loadtesting-data",
"s3file": "folder/payload.uri",
"name": "payload.uri"
}
]
}
В файле meta.json
можно указать параметр multi
, присвоив ему значение, равное желаемому количеству агентов, на которых тест будет выполняться одновременно.
{
"multi": 3
}
WARNING: если на момент запуска теста, необходимое количество агентов не будет подключено к сервису, тест не запустится.
По умолчанию, система запуска уже выполняет некоторые проверки. В каждом тесте эти проверки можно переопределить, добавив в папку с тестом проверочные скрипты check_summary.sh
и check_result.sh
.
По завершению выполнения теста, эти скрипты будут вызваны в виде, аналогичном следующему:
# download results
yc --format json loadtesting test get "$test_id" > summary.json
yc --format json loadtesting test get-report-table "$test_id" > report.json
# check
bash $test_dir/check_summary.sh summary.json
rc1=$?
bash $test_dir/check_report.sh report.json
rc2=$?
((rc1 == 0 && rc2 == 0))
Тест считается упавшим, если один из скриптов завершился с ошибкой (exit_code != 0
).
Прим: полностью выключить проверки можно, указав YC_LT_SKIP_TEST_CHECK=1