Первый прогон автотестов за 30 минут

Путь от «тесты гоняются только локально» до «результаты каждого запуска видны в DoQA в одном прогоне». Проходим его целиком: доступы → переменные в пайплайне → запуск из DoQA → просмотр результата. Отдельные шаги подробно описаны в Автотестах — здесь мы собираем их в рабочий порядок.

🎯 Задача

Прогнать автотесты в GitLab CI так, чтобы результаты пришли в конкретный прогон DoQA, а не расползлись по новым, и увидеть статусы и ошибки в интерфейсе.

💡 Решение

Запустить прогон из DoQA способом «Запуск автотестов»: DoQA сама создаёт прогон, стартует пайплайн и передаёт в него DOQA_SPACE_ID. Пайплайн скачивает doqa-cli, забирает у DoQA тест-план (в нём runId нужного прогона) и шлёт результаты через watch. Справочник по каждому шагу — Автотесты, контракт тест-плана — Как пайплайн выбирает тесты для запуска.

📝 Что понадобится

GitLab как CI/CD-система подключён администратором, а нужные проекты привязаны к пространству — см. Интеграции с CI/CD. Без этого в диалоге запуска не будет списка систем.
Право на создание и редактирование прогонов в пространстве.
API-токен проекта DoQA — им авторизуется отправка отчёта и запрос тест-плана. Как создать — Создание API-токена.
ID пространства — Как узнать ID пространства.
Тестовый фреймворк, который формирует сырые данные Allure (allure-results). Поддерживаемые форматы — Поддерживаемые форматы отчетов.
doqa-cli — Скачивание doqa-cli.

⏱ Время: ≈30 мин

Шаг 1. Собрать доступы

Понадобятся две вещи, которые нужны и для отправки отчёта, и для запроса тест-плана:

API-токен проекта. Настройки администратора → «Проекты» → нужный проект → вкладка «API-токены» → создать токен. Одним токеном можно загружать отчёты в любое пространство этого проекта. Подробно — Создание API-токена.
ID пространства. Откройте пространство в браузере: в адресе .../detail/1/2/cases второе число — это ID. Подробно — Как узнать ID пространства.

✅ Результат: у вас на руках токен проекта и числовой ID пространства.

Шаг 2. Прописать переменные окружения в CI

В GitLab: Settings → CI/CD → Variables. Токен заведите с флагом Masked.

Переменная	Значение	Зачем
`DOQA_ENDPOINT`	адрес вашего экземпляра, например `https://company.doqa.app`	куда слать отчёт и запрос плана
`DOQA_TOKEN`	API-токен проекта из Шага 1	авторизация отправки и тест-плана
`DOQA_SPACE_ID`	ID пространства из Шага 1	в какое пространство идут результаты

DOQA_SPACE_ID вручную нужен только пайплайнам, которые стартуют сами — по коммиту или расписанию. При запуске из DoQA (наш случай, Шаг 4) значение приходит в пайплайн автоматически и перекрывает заданное в настройках CI. Полное описание переменных — Переменные окружения.

✅ Результат: в проекте CI заведены три переменные, токен замаскирован.

Шаг 3. Встроить doqa-cli в пайплайн

Добавьте в .gitlab-ci.yml этап, который скачивает doqa-cli, забирает тест-план и запускает тесты. Основной способ — watch: он отправляет результаты по мере готовности, и прогресс виден в прогоне ещё до конца пайплайна.

watch (реальное время)

stages:
  - test

autotests:
  stage: test
  before_script:
    # Скачиваем актуальную doqa-cli и делаем исполняемой
    - curl -fsSL https://doqa.app/downloads/doqa-cli -o doqa-cli
    - chmod +x doqa-cli
    # Забираем тест-план: список Allure ID и runId прогона, куда уйдут результаты
    - >
      curl -fsSL --get "$DOQA_ENDPOINT/api/integrations/ci/test-plan"
      --data-urlencode "pipeline_id=$CI_PIPELINE_ID"
      --data-urlencode "ci_project_id=$CI_PROJECT_ID"
      --data-urlencode "space_id=$DOQA_SPACE_ID"
      --data-urlencode "token=$DOQA_TOKEN"
      -o test-plan.json
    - cat test-plan.json
  script:
    # Запускаем тесты через watch — результаты уходят в прогон по мере появления файлов.
    # Фильтрацию по Allure ID из test-plan.json настройте под свой фреймворк и раннер.
    - ./doqa-cli watch -- mvn -B -Dallure.results.directory=allure-results test
  artifacts:
    when: always
    paths:
      - allure-results
    expire_in: 1 week

report (в конце, всегда новый прогон)

stages:
  - test

autotests:
  stage: test
  script:
    - mvn -B -Dallure.results.directory=allure-results test
  after_script:
    - apt-get update && apt-get install -y zip curl
    - curl -fsSL https://doqa.app/downloads/doqa-cli -o doqa-cli
    - chmod +x doqa-cli
    - zip -r allure-results.zip allure-results
    # report загружает готовый архив и создаёт ОТДЕЛЬНЫЙ новый прогон
    - ./doqa-cli report "$DOQA_ENDPOINT/api/autotests/report" "$DOQA_SPACE_ID" "$DOQA_TOKEN" "allure-results.zip" allure
  artifacts:
    when: always
    paths:
      - allure-results/
      - allure-results.zip
    expire_in: 1 week

Что учесть:

всё после двойного тире (--) — ваша исходная команда запуска тестов; сама doqa-cli её не меняет;
если фреймворк формирует отчёты сразу в двух форматах, JUnit XML и Allure, doqa-cli берёт Allure;
watch отправляет результаты по мере появления файлов — настройте фреймворк на генерацию отчётов в процессе, а не в самом конце;
report — для случая, когда реальное время не нужно; он всегда создаёт новый прогон, поэтому для нашей задачи (результаты в запущенный из DoQA прогон) используйте вкладку watch.

Подробности по командам — Команда watch и Команда report.

✅ Результат: в .gitlab-ci.yml есть этап, который скачивает doqa-cli, получает тест-план и отправляет результаты в DoQA.

Шаг 4. Запустить прогон из DoQA

Именно этот способ гарантирует, что результаты придут в один прогон.

На вкладке «Прогоны» нажмите «Создать прогон».
В поле «Способ создания» выберите «Запуск автотестов».
Укажите «CI/CD система», «Проект» и «Ветку».
Нажмите «Сохранить».

DoQA создаёт пустой прогон в статусе «В работе», стартует пайплайн и передаёт в него DOQA_SPACE_ID. Пайплайн запрашивает тест-план и получает runId этого прогона — результаты стекаются именно в него, по мере выполнения тестов. Когда пайплайн в GitLab завершится, DoQA сама переведёт прогон в «Завершен»; вручную закрывать не нужно. Пайплайн, застрявший в pending дольше 60 минут, закрывается как неуспешный.

Подробнее о полях — Создание прогона через запуск автотестов и Запуск автотестов из DoQA.

✅ Результат: в списке появился прогон «В работе», и его таблица наполняется результатами по мере прохождения тестов.

Шаг 5. Посмотреть результат

Откройте прогон и выберите автотест в таблице. Пока результаты не приехали, в карточке висит «Результаты автотестирования все еще обрабатываются». Когда результат есть, в карточке видно:

«Результаты» — заголовок ошибки и её описание со стек-трейсом;
«Output» — вывод теста, если он есть в отчёте;
«Свойства» — properties автотеста из отчёта.

Исполнителем автотеста указана «Автоматизация». По упавшему тесту прямо из карточки можно завести баг-репорт или оставить комментарий. Полное описание карточки — Просмотр результата автотеста.

✅ Результат: вы видите статусы автотестов и тексты ошибок в том самом прогоне, который запустили из DoQA. Первый прогон настроен.

⚠️ Возможные трудности

Результаты уехали в новый прогон вместо запущенного. Самая частая боль. В какой прогон попадут результаты, решает не отправка отчёта сама по себе, а то, каким способом запущен пайплайн:

«Запуск автотестов» из DoQA (наш Шаг 4). DoQA заранее создаёт пустой прогон и запускает пайплайн. Тест-план возвращает runId этого прогона и isNewRun: true — «прогон уже создан под этот запуск». Результаты, отправленные через watch, наполняют именно его. Второго прогона не появится.
Запуск из плеера существующего прогона или «Пройти заново». Тест-план возвращает runId существующего прогона и isNewRun: false. Результаты дописываются в него.
Пайплайн стартовал сам — по коммиту или расписанию, не из DoQA. Прогона в DoQA ещё нет, и создаётся новый. Это нормально для ночных прогонов, но если вы ждали результаты в конкретный прогон — запускайте из DoQA, а не по расписанию.

Правило одно: чтобы результаты легли в нужный прогон, пайплайн должен запросить тест-план и слать результаты через watch. Команда report (вкладка справа в Шаге 3) этот runId не использует и всегда создаёт отдельный новый прогон — не применяйте её, когда ждёте результаты в уже запущенный прогон.

Прогонялись все тесты проекта, а не выбранные. Пайплайн не забрал тест-план или не отфильтровал тесты по полученным Allure ID. Проверьте шаг с запросом ci/test-plan и то, что раннер использует ID из test-plan.json. Все четыре параметра запроса обязательны — см. Как пайплайн выбирает тесты для запуска.

В диалоге запуска нет списка CI/CD-систем. GitLab не подключён как CI/CD-система или к пространству не привязаны проекты. Это делает администратор — Подключение GitLab и Привязка проектов к пространству.

В карточке автотеста нет ошибки, хотя тест упал. Проверьте, что фреймворк кладёт сырые данные Allure в allure-results, а не готовый allure-report: с версии 4.0 DoQA обрабатывает только сырые данные. Форматы — Поддерживаемые форматы отчетов.

📚 Смотрите также

Автотесты — как результаты попадают в DoQA, команды doqa-cli и контракт тест-плана
Интеграции с CI/CD — подключение GitLab и привязка проектов к пространству
Прогоны — где живут результаты и как проходит прогон
Публичный API — токены и методы для работы из скриптов