Как это устроено

Схема из трёх частей, без сервера и без агентов-посредников:

  1. Набор проверок. В приложении есть панель CI/CD: отмечаете галочками нужные проверки и получаете один JSON-файл. В нём запросы, тест-кейсы, переменные коллекций, папок и проверок, настройки поиска логов — всё, что нужно для повторяемого прогона.
  2. Консольный раннер. Рядом с приложением ставится checkcraft-cli: он читает набор, выполняет запросы и правила и пишет отчёты. Интерфейс ему не нужен, поэтому он работает на агенте без графической среды.
  3. Отчёт для сборки. На выходе JUnit XML, который умеют читать Jenkins, GitLab, GitHub Actions и TeamCity, плюс JSON для своих дашбордов. Сборка падает по коду выхода, а не по разбору логов.
Секретов в файле нет: пароли, токены, а также адрес и учётная запись Kibana заменяются ссылками на переменные. Имена панель показывает списком, а значения задаёт сервер сборки из своих секретов — внутренний адрес журналов в репозитории такая же утечка, как пароль.

Шаг 1: выгрузить набор из приложения

Кнопка CI/CD в верхней панели открывает окно выбора. Слева дерево коллекций, папок и проверок с галочками, справа — окружение, пути к отчётам и система сборки. Нажимаете «Сохранить набор» и кладёте файл в репозиторий рядом с кодом, например в checkcraft/checks.ccbundle.json. Файл текстовый, читаемый и нормально показывается в диффе: видно, какую проверку изменили в этом коммите.

Шаг 2: добавить один шаг в пайплайн

Сниппет под выбранную систему сборки панель формирует сама — с путями отчётов и перечисленными переменными, останется вставить его в пайплайн. Для Jenkins это выглядит так:

stage('API-проверки') {
  steps {
    withCredentials([usernamePassword(credentialsId: 'checkcraft-account',
                     usernameVariable: 'CHECKCRAFT_USER',
                     passwordVariable: 'CHECKCRAFT_PASSWORD')]) {
      sh '/opt/checkcraft/checkcraft-cli --bundle checkcraft/checks.ccbundle.json \
          --report-junit checkcraft/report-junit.xml --report-json checkcraft/report.json'
    }
  }
}
post { always { junit 'checkcraft/report-junit.xml' } }

Для GitLab CI то же самое умещается в задачу с artifacts:reports:junit, для GitHub Actions — в шаг с секретами в env. Отдельного плагина ставить не нужно ни там, ни там.

Шаг 3: понять результат без чтения консоли

Раннер возвращает коды выхода, по которым сборка отличает разные ситуации:

  • 0 — все проверки прошли;
  • 1 — есть расхождения: непройденные правила или сорванные запросы;
  • 2 — проблема с аргументами, файлом набора или не заданы переменные;
  • 3 — не подтверждён доступ к приложению;
  • 4 — внутренняя ошибка.

Разделение важное: сломанный пайплайн и найденный дефект — разные события, и на дашборде они не должны выглядеть одинаково. В JUnit-отчёте каждая проверка становится набором тестов, а каждое правило — отдельным тестом с текстом расхождения, поэтому на странице сборки сразу видно, что именно не совпало.

Что попадает под проверку в пайплайне

Раннер выполняет те же правила, что и приложение: статусы и заголовки, поля JSON и XML, размеры массивов, белые списки полей, вычисляемые выражения и сравнения сумм. Если у проверки настроен поиск логов, раннер берёт идентификатор трассировки из ответа, подтягивает записи и сверяет их с телом ответа — то есть в сборку уезжает не только «ответ 200», но и «в журнале списана та же сумма».

Полезные ключи для пайплайна: --filter запускает только проверки с подходящим именем (удобно для быстрого смоука на каждый коммит), --stop-on-failure обрывает прогон на первом падении, --skip-logs оставляет только HTTP, когда журналы недоступны из сети агента, а --var ИМЯ=значение подменяет адреса и учётные данные под конкретный стенд.

Почему это дешевле, чем писать тесты заново

Автотесты на код требуют разработчика тестов, ревью, окружения сборки и постоянного сопровождения — и чаще всего дублируют то, что уже проверяется руками. Выгрузка готовых проверок убирает дублирование: один и тот же набор используется при ручной проверке и в пайплайне, а изменение правила делается там, где его удобнее делать — в интерфейсе, а не в коде.

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

С чего начать

Скачайте приложение для проверки API, соберите одну проверку на своём стенде, выгрузите её через панель CI/CD и добавьте шаг в тестовую ветку пайплайна. Доступ бесплатный, без заявок и действует до окончания беты. Приложение и раннер работают на Windows и Linux, данные проекта остаются на вашей машине и на ваших агентах.

Полезное рядом: проверка API вместе с логами, правила для JSON и XML, сравнение с Postman.