Mockarty CLI

Mockarty CLI – это мощный инструмент командной строки для мокирования API, тестирования, фаззинга, нагрузочного тестирования и интеграции с CI/CD. Работает в автономном режиме (бесплатно, сервер не требуется) и в подключённом режиме (с сервером Mockarty для полного доступа к возможностям платформы).

Без зависимостей. Один бинарник. Работает офлайн. 5 форматов отчётов.

URL-адреса в примерах: Во всех примерах используется localhost:5770 как адрес Mockarty по умолчанию. Если ваш экземпляр работает на удалённом сервере, замените localhost:5770 на реальный адрес (например, https://mockarty.company.com или http://192.168.1.50:5770). Подробнее — в разделе Полезные функции и советы.

Установка

macOS / Linux

curl -sSL https://mockarty.ru/install.sh | sh

Homebrew

brew install mockarty/tap/mockarty-cli

Прямая загрузка

Скачайте готовый бинарник для вашей платформы со
страницы релизов и положите
его в PATH:

chmod +x mockarty-cli-* && sudo mv mockarty-cli-* /usr/local/bin/mockarty-cli

Docker

docker run --rm mockarty/cli version

Проверка установки:

mockarty-cli version

Быстрый старт

1. Запуск автономного мок-сервера

echo '{"id":"hello","http":{"route":"/hello/:name","httpMethod":"GET"},
  "response":{"statusCode":200,"payload":{"message":"Hello, $.pathParam.name!","uuid":"$.fake.UUID"}}}' > mock.json

mockarty-cli serve -f mock.json --port 8080
curl http://localhost:8080/hello/World
# {"message":"Hello, World!","uuid":"a1b2c3d4-..."}

2. Запуск коллекции API-тестов

mockarty-cli run -f collection.json --reporter cli

3. Создание мока на подключённом сервере

mockarty-cli login --server https://mockarty.company.com --token mk_xxx
mockarty-cli mock create -f mock.json

Конфигурация

Настройка URL сервера

По умолчанию mockarty-cli подключается к локальному инстансу Mockarty (http://localhost:5770). Переопределить таргет — self-hosted-узел или air-gapped-развёртывание — можно одним из четырёх способов. Строки выше перебивают строки ниже.

Старая переменная MOCKARTY_SERVER_URL по-прежнему работает как синоним MOCKARTY_SERVER — старые CI-скрипты не сломаются. Если установлены обе, побеждает MOCKARTY_SERVER.

Подробнее — в Подключение к серверу.

Аутентификация

# OAuth (рекомендуется; использует текущий URL сервера — облако по умолчанию)
mockarty-cli auth login

# API-токен (CI/CD, скрипты)
mockarty-cli login --server https://mockarty.company.com --token mk_xxx

# Логин/пароль (интерактивный режим)
mockarty-cli login --server https://mockarty.company.com --user admin --password secret

# Указать имя контекста явно
mockarty-cli login --server https://mockarty.company.com --token mk_xxx --name production

# Проверить текущий статус
mockarty-cli login --status

Переменные окружения (переопределяют конфигурацию, идеально для CI/CD):

Расположение файла конфигурации: ~/.mockarty/config.json

Контексты

Контексты позволяют управлять несколькими подключениями к серверам (аналогично контекстам kubectl):

# Просмотр всех контекстов
mockarty-cli config view

# Список контекстов в виде таблицы
mockarty-cli config get-contexts

# Переключение контекста
mockarty-cli config use-context production

# Создание/обновление контекста вручную
mockarty-cli config set-context staging --server https://staging.company.com --token mk_xxx --namespace test

# Удаление контекста
mockarty-cli config delete-context old-server

Справочник команд

Мок-сервер (serve) – Автономный режим

Запуск локального мок-сервера с полноценным движком резолвера Mockarty. Сервер не требуется.

mockarty-cli serve -f mocks/                              # Из директории
mockarty-cli serve -f mock.json --port 9090               # Один файл, свой порт
mockarty-cli serve --har traffic.har                      # Из HAR-записи
mockarty-cli serve -f mocks/ --proto protos/ --grpc-port 50051  # С gRPC
mockarty-cli serve -f mocks/ --watch                      # Горячая перезагрузка при изменениях
mockarty-cli serve -f mocks/ --cors=false                 # Отключить CORS

Поддерживаемые протоколы: HTTP/REST, gRPC (с --proto), SOAP, MCP

Команда serve предоставляет SDK-совместимый CRUD API по адресу /api/v1/mocks, поэтому SDK на Go, Python и Java работают как с автономным serve, так и с admin node.

Управление моками (mock) – Подключённый режим

Управление моками на удалённом сервере Mockarty.

mockarty-cli mock create -f mock.json             # Создать/обновить из файла
mockarty-cli mock create -f mocks/                # Все файлы в директории
cat mock.json | mockarty-cli mock create -f -     # Из stdin

mockarty-cli mock list                            # Список всех моков
mockarty-cli mock list -o json                    # Вывод в JSON
mockarty-cli mock list -o wide                    # Расширенная таблица
mockarty-cli mock list --protocol grpc            # Фильтр по протоколу

mockarty-cli mock get <mock-id>                   # Получить мок по ID
mockarty-cli mock delete <mock-id>                # Удалить мок
mockarty-cli mock logs <mock-id>                  # Просмотр последних вызовов

mockarty-cli mock export -d backup/               # Экспорт в директорию
mockarty-cli mock import -f backup/               # Импорт из файлов

mockarty-cli mock apply -f mocks/                 # Декларативное создание/обновление
mockarty-cli mock apply -f mocks/ --prune         # + удалить моки, которых нет в файлах

Команда apply работает как kubectl apply – создаёт новые моки, обновляет существующие, а с флагом --prune удаляет с сервера моки, отсутствующие в ваших локальных файлах.

Тестирование API (run)

Запуск коллекций API-тестов с assertions и цепочкой переменных.

mockarty-cli run -f collection.json               # Формат Mockarty
mockarty-cli run -f postman-export.json           # Postman v2.1 (автоопределение)
mockarty-cli run --har traffic.har                # Из HAR-записи
mockarty-cli run -f tests/                        # Все коллекции в директории

Форматы отчётов (все 5 можно использовать одновременно):

mockarty-cli run -f tests.json \
  --reporter cli \
  --reporter json:results.json \
  --reporter junit:report.xml \
  --reporter allure:allure-results

Коды выхода: 0 = все шаги прошли и все запрошенные отчёты записаны · 1 = шаг упал, не удалось записать отчёт или не выполнился ни один шаг (опечатка в dependsOn пропускает весь манифест — «ничего не проверено» это не успех) · 2 = прогон не начался (плохой флаг, нечитаемый манифест или лимит бесплатного тарифа).

Фаззинг безопасности (fuzz)

Фаззинг API-эндпоинтов для поиска уязвимостей. Бесплатный тариф: 1 поток, максимум 2 минуты.

mockarty-cli fuzz --target http://api.com --spec openapi.yaml
mockarty-cli fuzz --target http://api.com --har traffic.har --strategy all
mockarty-cli fuzz --target http://api.com --spec openapi.yaml \
  --strategy mutation --duration 5m --threads 4 \
  --out json:findings.json --out junit:fuzz-report.xml

Стратегии:

Нагрузочное тестирование (perf)

Нагрузочное тестирование с JavaScript-сценариями. Локальный CLI без сервера допускает до 500 VU и 2 минут на прогон.

mockarty-cli perf run script.js
mockarty-cli perf run script.js --vus 50 --duration 5m
mockarty-cli perf run script.js --rps 200
mockarty-cli perf run --har traffic.har --vus 5 --duration 30s
mockarty-cli perf run script.js --out json:results.json --out html:report.html

Контрактное тестирование (contract)

Валидация моков, верификация реальных сервисов, обнаружение дрейфа, проверка безопасности деплоя и управление реестром API.

# Валидация моков по спецификации (требуется подключённый сервер)
mockarty-cli contract validate --spec openapi.yaml

# Верификация живого сервиса по спецификации
mockarty-cli contract verify --spec openapi.yaml --target http://api.staging.com
mockarty-cli contract verify --spec openapi.yaml --target http://api.staging.com --timeout 120s

# Обнаружение дрейфа моков — сравнение моков с ответами реального API
mockarty-cli contract drift --target http://api.staging.com

# Проверка безопасности деплоя версии сервиса
mockarty-cli contract can-i-deploy --participant user-service --version "$GIT_SHA" --to production
mockarty-cli contract can-i-deploy --contracts contract-id-1,contract-id-2

# После успешного деплоя запишите его в леджер — can-i-deploy начнёт резолвить реальные версии
mockarty-cli contract record-deployment --service user-service --version "$GIT_SHA" --environment production

# Реестр API — список опубликованных API-спецификаций
mockarty-cli contract registry list

Коды выхода: 0 = контракт валиден / безопасно деплоить · 1 = нарушения, дрейф или заблокированный деплой · 2 = проверка не выполнялась (не задан флаг, не читается спека, сервер недоступен). С -o json код тот же, что и у человекочитаемого вывода.

Хаос-инженерия (chaos) – PRO

Запуск хаос-экспериментов против Kubernetes-кластеров. Требуется PRO-лицензия и настроенный K8s-кластер.

Управление кластерами:

# Добавить K8s-кластер в конфигурацию CLI
mockarty-cli chaos cluster add --name staging --kubeconfig ~/.kube/config --context staging-ctx
mockarty-cli chaos cluster add --name prod --kubeconfig ~/.kube/prod.yaml \
  --allowed-namespaces app,test --denied-namespaces kube-system

# Список, переключение, проверка, инспекция, удаление кластеров
mockarty-cli chaos cluster list
mockarty-cli chaos cluster use staging
mockarty-cli chaos cluster test
mockarty-cli chaos cluster info
mockarty-cli chaos cluster remove old-cluster

Запуск экспериментов:

# Запуск из флагов
mockarty-cli chaos run --type pod_kill --k8s-namespace app --selector app=web --duration 5m
mockarty-cli chaos run --type network_partition --deployment my-svc --k8s-namespace app --duration 2m --auto-rollback

# Запуск из YAML-файла
mockarty-cli chaos run -f experiment.yaml

# Запуск из пресета
mockarty-cli chaos preset list
mockarty-cli chaos preset run --preset chaos-monkey --k8s-namespace app --selector app=web
mockarty-cli chaos preset run --preset network-partition --k8s-namespace app --selector app=api --duration 3m

Жизненный цикл экспериментов:

mockarty-cli chaos list                               # Список экспериментов
mockarty-cli chaos list --status active               # Фильтр по статусу
mockarty-cli chaos get <experiment-id>                # Детали эксперимента
mockarty-cli chaos abort <experiment-id>              # Прервать активный эксперимент
mockarty-cli chaos report <experiment-id>             # JSON-отчёт
mockarty-cli chaos report <experiment-id> --format html --output report.html

Управление оператором (K8s):

mockarty-cli chaos operator install                   # Установить оператор хаоса
mockarty-cli chaos operator install --namespace mockarty-chaos
mockarty-cli chaos operator status                    # Проверить состояние оператора
mockarty-cli chaos operator uninstall                 # Удалить оператор

install останавливается и возвращает не ноль, если не удалось создать
предпосылку (ServiceAccount, ClusterRole, binding): оператор без своих прав
запустится и будет падать на каждом эксперименте, поэтому он вообще не
разворачивается. status возвращает не ноль, когда оператора нет или он не
готов, — на этом можно ждать в CI. uninstall возвращает не ноль, пока в
кластере остаётся хоть один объект. chaos cluster test проходит только
если отработала и проба возможностей — подключиться это лёгкая половина.

Интерактивный TUI:

mockarty-cli tui chaos                                # Интерактивный TUI

Встроенные пресеты: chaos-monkey, network-partition, scale-to-zero, resource-pressure, rolling-restart-storm, dns-disruption.

Типы сбоев: pod_kill, pod_kill_random, network_partition, network_delay, network_loss, deployment_restart, scale, node_drain, resource_stress, dns_disruption, io_chaos, time_chaos.

Управление кластером (cluster) – Подключённый режим

Управление Kubernetes-кластером Mockarty через API admin-узла.

mockarty-cli cluster status                            # Показать статус кластера
mockarty-cli cluster upgrade --tag 1.3.0               # Обновить все компоненты
mockarty-cli cluster scale resolver --replicas 5       # Масштабировать компонент
mockarty-cli cluster restart runner                    # Rolling-перезапуск
mockarty-cli cluster logs <pod-name> --tail 100        # Стриминг логов пода
mockarty-cli cluster logs <pod-name> --follow          # Следить за логами

# Добавление/удаление интеграций
mockarty-cli cluster add-runner --name sandbox-runner --namespace sandbox
mockarty-cli cluster add-resolver --name shared-resolver --scope admin --replicas 2
mockarty-cli cluster remove-integration sandbox-runner

Генерация кода (generate)

Генерация определений моков из API-спецификаций, HAR-записей и коллекций Postman.

# Из OpenAPI (через подключённый сервер)
mockarty-cli generate openapi spec.yaml -o mocks/
mockarty-cli generate openapi spec.yaml --upload    # Сгенерировать и загрузить на сервер

# Из HAR-записи (локально)
mockarty-cli generate har recording.har -o mocks/

# Из коллекции Postman (локально)
mockarty-cli generate postman collection.json -o mocks/

Утилиты

Проверка здоровья:

mockarty-cli health                        # Проверить состояние сервера
mockarty-cli health --verbose              # Подробная информация (версия, аптайм, лицензия)
mockarty-cli health --wait --timeout 60s   # Ждать до состояния healthy

Ввод HTTP-матчера:

mockarty-cli matcher status                # Режим, ревизия снимка и находки по пространствам имён
mockarty-cli matcher status -o json        # Тот же отчёт в JSON — для пайплайна

Режим матчера выбирается при запуске через MOCKARTY_HTTP_MATCH_MODE (off,
shadow, on), поэтому команда только читает: ввод и откат разнесены на один
перезапуск. В shadow находки — это расхождения скомпилированного и старого
матчера, поэтому пространство имён без находок наблюдалось согласованным. В on
находка записывает запрос, который скомпилированный индекс не смог обслужить и
который отдал старый матчер, — так деградировавший ввод остаётся видимым. Находки
не меняют код возврата: это доказательства о миграции, а не отказ сервера.

Ожидание готовности (CI/CD):

mockarty-cli wait                                  # Ждать healthy-статуса
mockarty-cli wait --mocks user-api,order-api       # Ждать конкретных моков
mockarty-cli wait --mock-count 5                   # Ждать N моков
mockarty-cli wait --timeout 120s --interval 5s     # Свои таймауты

Проброс портов:

mockarty-cli tunnel --local 5770 --remote server:5770
mockarty-cli tunnel --local 50051 --remote server:50051   # gRPC

Управление хранилищами (подключённый режим):

mockarty-cli store global get                          # Получить все значения глобального хранилища
mockarty-cli store global set <key> <value>            # Установить пару ключ-значение
mockarty-cli store global delete <key>                 # Удалить ключ
mockarty-cli store chain get <chain-id>                # Получить значения цепочного хранилища
mockarty-cli store chain set <chain-id> <key> <value>  # Установить пару ключ-значение в цепочке
mockarty-cli store chain delete <chain-id> <key>       # Удалить ключ из цепочки

Управление пространствами имён (подключённый режим): (алиас: ns)

mockarty-cli namespace current                 # Показать текущее пространство имён
mockarty-cli namespace use <name>              # Установить пространство имён по умолчанию
mockarty-cli namespace list                    # Список доступных пространств имён
mockarty-cli namespace create <name>           # Создать новое пространство имён
# Короткая форма:
mockarty-cli ns current

Экспорт журнала аудита (admin):

# CSV-архив для compliance-аудита
mockarty-cli audit export --format csv --output audit.csv

# Syslog RFC 5424 — одна запись на строку, поток в SIEM-коллектор
mockarty-cli audit export --format syslog > audit.log

# ArcSight CEF — прямой ingestion в SIEM (Splunk/ArcSight/QRadar/MaxPatrol/KUMA/RuSIEM)
mockarty-cli audit export --format cef --output audit.cef

# Фильтры по пользователю, действию, ресурсу, namespace, временному окну (мс от эпохи)
mockarty-cli audit export --format json --user-id u-42 --action login \
    --from 1712345678000 --to 1712431678000

Управление токенами (PRO):

mockarty-cli token create --name "ci-runner" --expires 90d
mockarty-cli token list
mockarty-cli token delete <token-id>

Интерактивный TUI:

mockarty-cli tui
mockarty-cli tui --server http://localhost:8080

Навигация стрелками, Enter для перехода внутрь, Esc для возврата, q для выхода. Горячие клавиши: c создать, e редактировать, d удалить, n новый тест, u загрузить, / поиск.

Сниффер трафика (PRO):

mockarty-cli sniff --target http://real-api.com --port 9090 -o traffic.har
# Направьте ваше приложение на localhost:9090, Ctrl+C для остановки и сохранения HAR

AI-агент чат (PRO):

mockarty-cli agent "create a mock for GET /api/users returning a list"
mockarty-cli agent                  # Интерактивный режим чата

Проверяйте самообученные наблюдения до того, как они попадут в следующие миссии:

mockarty-cli agent knowledge review list --state candidate
mockarty-cli agent knowledge review show <id>
mockarty-cli agent knowledge review decide <id> --decision publish \
    --expected-version 1 --reason "Подтверждено доказательством из миссии" \
    --idempotency-key review-<id>-v1

Решение принимают владельцы и администраторы пространства; обычные участники
могут изучать записи. --state published|superseded|expired|deleted открывает
историю жизненного цикла.

Если после обновления появилась восстанавливаемая история чата, созданная до внедрения привязки к пространствам имён, проверьте её явно. Команда списка показывает только метаданные; экспорт записывает историю в приватный файл и не перезаписывает его без флага --force. Исходное пространство имён неизвестно, поэтому для восстановления требуется выбрать целевое пространство и явно подтвердить это:

mockarty-cli agent sessions legacy list
mockarty-cli agent sessions legacy export <legacy-session-id> \
    --file legacy-session.json
mockarty-cli agent sessions legacy claim <legacy-session-id> \
    --namespace payments --acknowledge-unknown-origin

Для следующей страницы метаданных используйте --cursor, а для следующей страницы экспорта — --after-event-id, если ответ сообщает о наличии продолжения. Просматривать и восстанавливать изолированную историю может только исходная учётная запись; для восстановления также нужен доступ на запись в выбранное пространство имён.

Резервное копирование/восстановление (PRO):

mockarty-cli backup create
mockarty-cli backup list
mockarty-cli backup download <id> -o backup.tar.gz

Установка платформы (install, update, setup):

# Установка компонентов платформы
mockarty-cli install mockarty                             # Скачать последний бинарник
mockarty-cli install mockarty --mode docker-compose       # Сгенерировать docker-compose.yml
mockarty-cli install mockarty --mode sqlite               # Режим одного бинарника на SQLite
mockarty-cli install --all                                # Установить все компоненты
mockarty-cli install mockarty --version 1.2.3             # Конкретная версия

# Проверка обновлений
mockarty-cli update

# Сгенерировать конфигурацию развёртывания без скачивания бинарников
mockarty-cli setup docker-compose
mockarty-cli setup env

Управление лицензией:

mockarty-cli license                        # Показать информацию о текущей лицензии
mockarty-cli license features               # Список всех возможностей и их доступность
mockarty-cli license activate <key>         # Активировать PRO-ключ

Версия и выход:

mockarty-cli version                        # Показать версию CLI
mockarty-cli logout                         # Очистить сохранённые учётные данные

Автодополнение в оболочке:

mockarty-cli completion bash|zsh|fish|powershell
# Перенаправьте вывод в директорию автодополнений вашей оболочки

Интеграция с CI/CD

GitHub Actions

name: API Tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Установка Mockarty CLI
        run: curl -sSL https://mockarty.ru/install.sh | sh

      - name: Запуск мок-сервера
        run: mockarty-cli serve -f mocks/ --port 8080 &

      - name: Ожидание готовности сервера
        run: mockarty-cli wait --server http://localhost:8080 --timeout 30s

      - name: Запуск API-тестов
        run: |
          mockarty-cli run -f tests/ \
            --reporter cli \
            --reporter junit:report.xml

      - name: Фаззинг безопасности
        run: |
          mockarty-cli fuzz --target http://localhost:8080 \
            --spec openapi.yaml \
            --out junit:fuzz-report.xml

      - name: Загрузка результатов тестов
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-reports
          path: |
            report.xml
            report.html
            fuzz-report.xml

GitLab CI

api-tests:
  image: mockarty/cli:latest
  script:
    - mockarty-cli serve -f mocks/ --port 8080 &
    - mockarty-cli wait --server http://localhost:8080
    - mockarty-cli run -f tests/ --reporter junit:report.xml --reporter allure:allure-results
    - mockarty-cli fuzz --target http://localhost:8080 --spec openapi.yaml --out junit:fuzz-report.xml
  artifacts:
    when: always
    reports:
      junit: [report.xml, fuzz-report.xml]
    paths: [allure-results/]

Коды выхода упрощают интеграцию с CI: 0 = успех · 1 = работа выполнена и провалилась · 2 = работа не выполнялась (опечатка в подкоманде, неизвестный флаг, не настроен сервер или фича не входит в лицензию). Ветвитесь по 2, чтобы отличить сломанный шаг пайплайна от красных тестов. Полная таблица: справочник команд CLI.

Запуск того, что живёт на сервере

CI обычно не носит набор в своём репозитории — коллекция и профиль нагрузки
ведутся в Mockarty, а pipeline просто их запускает:

# Запустить коллекцию, которую ведут в интерфейсе, по имени
mockarty-cli run collection "Smoke"

# Отправить сохранённый профиль нагрузки на флот раннеров и дождаться результата
mockarty-cli perf run-config "Nightly checkout" --wait

Оба принимают UUID или имя. Имя, совпавшее с двумя сущностями, отклоняется со
списком кандидатов, а не угадывается: запустить не тот набор и отчитаться об
успехе хуже, чем остановиться.

Экспорт прогона обратно в Allure

mockarty-cli testplan report выгружает завершённый прогон тест-плана с
сервера как ZIP-архив Allure — тот же артефакт, что даёт кнопка экспорта
в интерфейсе. Это путь ухода без блокировки: исторические данные никогда не
запираются внутри продукта.

# Прогон → ZIP Allure, распаковать, собрать отчёт:
mockarty-cli testplan report <run-id> --plan <plan-id> --zip ./allure.zip
unzip -q ./allure.zip -d ./allure-results
allure generate ./allure-results -o ./allure-report
allure open ./allure-report

В распакованном каталоге есть всё, что нужно Allure:

• по одному <uuid>-result.json на тест, со стабильными historyId и
  testCaseId — чтобы тренды Allure сходились между прогонами;
• каждое вложение отдельным файлом <uuid>-attachment.<ext> со ссылкой
  из result-JSON;
• categories.json, environment.properties и executor.json.

Другие форматы — та же команда отдаёт прогон в том виде, который
потребляет ваш pipeline:

# JUnit XML для Jenkins / GitLab / GitHub Actions:
mockarty-cli testplan report <run-id> --plan <plan-id> --format junit --out ./junit.xml

# Markdown-сводка, чтобы вставить в merge request:
mockarty-cli testplan report <run-id> --plan <plan-id> --format markdown

Обратное направление — mockarty-cli allure upload ./allure-results —
загружает каталог Allure обратно в Mockarty, интеграция двусторонняя.

В CI эти команды сообщают, что произошло на самом деле. allure upload
падает, если в каталоге нет ни одного *-result.json (прогон ничего не
отчитал), если нет вложения, на которое ссылается результат или фикстура,
либо если запись прогона доехала, а крупное вложение загрузить не удалось.
При прерывании выгрузки команда также сообщает о неотправленных результатах.
allure launch close обычно последний шаг задания, поэтому он несёт настоящий итог лаунча:
код возврата не ноль, если лаунч закрыт как failed или в него не приехало ни
одного результата, в том числе при повторном закрытии старого пустого
лаунча. Внешний запуск ждёт выгрузки результатов перед завершением; для
действительно прерванного пайплайна есть --abort.
allure export падает, если записал бы пустой каталог: из такого
allure generate отчёт не соберёт.

Allure-результаты отправляются с постоянным ключом, вычисленным из UUID
результата и запуска. Если после POST оборвалось соединение или сервер вернул
5xx, CLI повторяет тот же payload и получает прежний ID прогона кейса.
Изменённый результат с прежним ключом даёт 409: новой попытке нужен новый
UUID результата. Перед использованием такого повтора обновите сервер
Mockarty: старые сборки не распознают ключ.

allurectl watch --results ./allure-results -- pytest принимает исходный
флаг каталога результатов. Watch ждёт, пока появится упомянутое вложение, и
завершается с ненулевым кодом, если после окончания тестовой команды
вложение всё ещё не удалось загрузить. Вложения фикстур, появившиеся после
результата, добавляются в его прогон по завершении тестовой команды. Пустой
каталог результатов также даёт ненулевой код.
Если тестовая команда завершилась с положительным ненулевым кодом,
allurectl watch возвращает в CI тот же код.

Команды allurectl watch и mockarty-cli allure watch по умолчанию создают
или возобновляют запуск для CI-задания, передают его ID тестовой команде,
загружают результаты и завершают запуск после доставки всех результатов и вложений.
Идентификаторы заданий GitLab и теги сборок Jenkins разделяют параллельные
задания. Локально приватный файл ключа в каталоге результатов переживает
прерывание процесса и удаляется после подтверждённого завершения. Свой
постоянный ключ задаётся через ALLURE_LAUNCH_KEY или MOCKARTY_LAUNCH_KEY.
Изменённый запрос с прежним ключом даёт 409; новому заданию нужен новый
ключ. При неполной загрузке watch оставляет запуск открытым для повтора.

Для загрузки без автоматического управления запуском используйте
--no-auto-launch с любым вариантом команды. Прежний флаг --auto-launch
также поддерживается. Если запуском управляет сам CI, сначала выполните
launch create, передайте ALLURE_LAUNCH_ID, запустите
watch --require-launch, затем завершите или отмените запуск в cleanup-шаге.
--require-launch проверяет namespace и активный статус до начала тестов;
ему нужен явный ID либо отдельный для задания ALLURE_LAUNCH_FILE, а не
общий cache-файл.

Для повторного запуска в удалённом GitLab или Jenkins команда allure rerun-failed --ci-config <id> передаёт заданию ID запуска. Если задание
запускает тесты через allurectl watch -- <команда>, CLI сам загрузит из
Mockarty план только с упавшими тестами и установит ALLURE_TESTPLAN_PATH
для дочерней команды. Заданию нужны адрес Mockarty, токен и namespace.
Если фреймворк запускается без allurectl watch, передайте в задание файл
из --out и установите там ALLURE_TESTPLAN_PATH.

Алиасы бинаря для allurectl и поддерживаемых команд testit-cli

mockarty-cli определяет имя бинаря, под которым он вызван, и
автоматически роутит в нужный subcommand. То есть CI-пайплайн,
который вызывает allurectl upload, может использовать алиас бинаря.
Алиас testit-cli направляет поддерживаемые команды, но существующие
адаптеры Test IT по-прежнему отправляют HTTP-запросы в Test IT. Как
подготовить результаты для Mockarty, описано в
руководстве Test IT:

Для каталога JUnit XML команда testit-cli results import --results ./reports
работает как алиас results upload; обе используют один импортёр результатов
Mockarty. Теги и ссылки прогона, а также HTTP-протокол официальных адаптеров
фреймворков требуют отдельного перехода.

# Symlink (Linux / macOS):
ln -s /usr/local/bin/mockarty-cli /usr/local/bin/allurectl
ln -s /usr/local/bin/mockarty-cli /usr/local/bin/testit-cli

# Или rename для герметичного образа:
cp mockarty-cli allurectl

# Или copy + rename в Dockerfile:
COPY mockarty-cli /usr/local/bin/allurectl

Дальше указываем стандартные env-vars на Mockarty-сервер и запускаем
те же команды что и раньше:

export ALLURE_ENDPOINT=https://mockarty.company.com
export ALLURE_TOKEN=mk_...
export ALLURE_PROJECT_ID=qa-team

allurectl upload ./allure-results        # → 'mockarty-cli allure upload'
allurectl launch create --name "PR-42"   # → 'mockarty-cli allure launch create'

Подкоманда testit принимает TMS_URL / TMS_PRIVATE_TOKEN /
TMS_PROJECT_ID как запасные настройки подключения. В них должны быть
URL Mockarty, его API-токен и пространство имён. Токен Test IT и числовой
ID проекта нельзя использовать вместо этих значений.

Если CI уже пишет JUnit XML, сохраните форму команд Test IT:

export TMS_URL=https://mockarty.company.com
export TMS_PRIVATE_TOKEN='YOUR_MOCKARTY_TOKEN'
export TMS_PROJECT_ID=qa-team
testit-cli testrun create --output ./testrun.id
testit-cli results upload -r ./junit-reports -ti "$(cat ./testrun.id)"
testit-cli testrun complete "$(cat ./testrun.id)"

Этот путь передаёт базовые результаты JUnit. Шаги, параметры и вложения
framework-адаптеров Test IT требуют более богатого адаптера либо
преобразованного JSON с файлами вложений; см.
руководство Test IT.

Распознаваемые имена (без учёта регистра, с опциональным .exe):

TestIT — конфигурационные UUID

Загрузка результатов может указать UUID конфигурации
(--configuration-id или TMS_CONFIGURATION_ID). Он сохраняется на
каждом результате; создание ad-hoc прогона не сохраняет ID конфигурации.
Команды в поддереве testit configuration позволяют
управлять значением без TestIT admin UI. testrun complete завершится
ошибкой, если в запуск не поступило ни одного результата, в том числе при
повторном завершении старого пустого запуска:

# Сгенерировать свежий UUID4 и сразу записать в env-var:
export TMS_CONFIGURATION_ID="$(mockarty-cli testit configuration generate)"

# Показать configuration UUID'ы, уже встречавшиеся в недавних
# external-прогонах текущего namespace (сортированно, без дублей):
mockarty-cli testit configuration list

# JSON-вывод для скриптов:
mockarty-cli testit configuration list --format json

list сканирует case_context.metadata.testit.configurationId
в недавних прогонах namespace и выводит уникальные значения.
generate — оффлайн, без сетевого вызова, просто UUID4 — работает
в cold-boot CI до настройки Mockarty endpoint.

Бесплатная версия vs PRO

PRO активируется подключением к лицензированному серверу Mockarty или установкой переменной MOCKARTY_LICENSE_KEY.

Форматы вывода

Все команды, отображающие данные, поддерживают флаг -o:

Примеры:

mockarty-cli mock list -o json | jq '.[] | .id'
mockarty-cli mock list -o quiet | xargs -I{} mockarty-cli mock delete {}
mockarty-cli mock list -o wide

Установка формата по умолчанию через переменную окружения: export MOCKARTY_OUTPUT=json

Глобальные флаги

Эти флаги работают со всеми командами:

Устранение проблем

Для проблем с подключением повторите команду с mockarty-cli health --verbose, чтобы увидеть полный ответ сервера, либо задайте MOCKARTY_OUTPUT=json для машинного формата.

Связанная документация

• Справочник API
• Руководство по SDK
• Системы хранилищ
• Контрактное тестирование
• Хаос-инженерия

Результаты выбранных кейсов из CI

Сохранённая CI job, запущенная для выбранных кейсов, получает приватный
MOCKARTY_CI_CONTEXT. Оставляйте его внутри этой job: не печатайте и не добавляйте
в файлы окружения тестового фреймворка. allure upload и allure watch используют
зафиксированные идентификаторы кейсов и отправляют только подходящие результаты
в существующий запуск Mockarty. После отправки они сообщают итог группы; если
результаты или файлы не удалось отправить, сообщают ошибочный итог. Сервер
продолжает показывать отсутствующие результаты выбранных кейсов как отсутствующие.

В этом режиме watch создаёт локальный ALLURE_TESTPLAN_PATH для фреймворков,
поддерживающих выбор тестов Allure, и удаляет приватный контекст из окружения
дочерней команды. Чтобы не выполнять невыбранные тесты, команда должна учитывать
testplan. Результаты ждут завершения команды: файлы setup и teardown включаются
до отправки результата. Большие файлы загружаются перед результатом. После
неоднозначного ответа на отправку выбранного результата CLI не повторяет запрос
автоматически; проверьте запуск перед новой попыткой.

Без приватного контекста действуют прежние правила upload и watch. CLI использует
настроенные endpoint, token и namespace Mockarty; для этих отчётов сервер
сторонней системы управления тестированием не требуется.