Тема
Подключение CI-систем
Чтобы запускать автотесты из DoQA и видеть статусы пайплайнов, пространству нужно подключение к CI-системе и привязка CI-проектов. Обе настройки живут на странице настроек пространства: откройте раздел «Автотесты» и нажмите кнопку настроек — откроется секция «CI/CD connections». Понадобится доступ к настройкам пространства.
Два уровня подключений
Подключения существуют на двух уровнях:
- Общее подключение тенанта — создаёт администратор, см. Интеграции с CI/CD. Оно видно всем пространствам. В настройках пространства такое подключение помечено чипом «Shared (inherited)»: его нельзя изменить или удалить из пространства, но можно проверять соединение и привязывать к нему CI-проекты.
- Подключения пространства — создаются в настройках самого пространства и видны только в нём.
Подключений может быть несколько, в том числе одного типа — например, несколько инстансов GitLab в одном пространстве.
Поддерживаемые CI-системы
DoQA работает с девятью CI-системами: GitLab, Jenkins, TeamCity, GitHub Actions, GitVerse (совместим с Gitea Actions), Bitbucket (облачные Pipelines), Azure DevOps, CircleCI, Bamboo.
Базовые операции — запуск пайплайна, чтение статуса, отмена пайплайна и ссылка на него — поддерживают все девять. Расширенные возможности различаются:
| CI-система | Вебхук о завершении | Управление джобами | Скачивание результатов из артефактов | Авто-настройка CI-переменных | Аутентификация в поле «Токен» |
|---|---|---|---|---|---|
| GitLab | да | да | да | да | персональный access token |
| Jenkins | да | только просмотр стадий | — | — | логин:api-токен |
| TeamCity | да | только отмена | — | — | Bearer-токен |
| GitHub Actions | да | только перезапуск | — | — | токен (Bearer) |
| GitVerse | да | — | — | — | токен Gitea |
| Bitbucket | да | — | — | — | логин:app_password или Bearer-токен |
| Azure DevOps | да | — | — | — | Personal Access Token |
| CircleCI | да | — | — | — | API-токен |
| Bamboo | да | — | — | — | логин:пароль или Bearer-токен |
Там, где нужна пара «логин + секрет», она вводится в поле «Токен» одной строкой через двоеточие (логин:токен). Значение без двоеточия Bitbucket и Bamboo трактуют как Bearer-токен.
Особенности провайдеров
Jenkins, GitHub Actions и GitVerse не сообщают идентификатор пайплайна в момент запуска — ссылка на пайплайн и его отмена могут быть недоступны, пока CI-система не пришлёт вебхук с реальным идентификатором. Bamboo умеет отменять сборку, только пока она стоит в очереди.
Создание подключения
- Откройте настройки пространства, секцию «CI/CD connections».
- Добавьте подключение и заполните форму.
- Перед сохранением проверьте соединение кнопкой «Test connection».
- Сохраните подключение.
Поля формы:
| Поле | Что указать |
|---|---|
| Тип | одна из девяти CI-систем. После сохранения тип изменить нельзя |
| Название | метка подключения, обязательна |
| Хост | адрес CI-системы, например https://gitlab.example.com |
| Токен | учётные данные для API CI-системы (что именно — см. столбец «Аутентификация» выше). При редактировании пустое поле означает «не менять токен» |
| Секрет вебхука | секрет для проверки подлинности входящих вебхуков, см. Вебхук подключения |
| Идентификаторы проекта | JSON-объект с идентификаторами проекта у провайдера, например {"job": "autotests"} |
Какие ключи ожидаются в поле «Идентификаторы проекта»:
Ключи идентификаторов по провайдерам
| Провайдер | Ключи |
|---|---|
| GitLab | projectId |
| Jenkins | job |
| TeamCity | buildTypeId |
| GitHub Actions, GitVerse | owner, repo, workflow |
| Bitbucket | workspace, repo_slug, опционально pipeline |
| Azure DevOps | organization, project, pipelineId |
| CircleCI | projectSlug |
| Bamboo | planKey |
Если обязательный ключ не задан, запуск пайплайна завершится ошибкой с указанием недостающего ключа.
Рядом со списком подключений доступен диалог «Как подключить автотесты» — короткие сниппеты команд отправки результатов и аннотаций для быстрого старта.
Проверка соединения
- «Test connection» в форме — проверка до сохранения: DoQA обращается к CI-системе с введёнными хостом и токеном и показывает результат.
- «Check» на карточке сохранённого подключения — повторная проверка; её результат и время сохраняются и показываются бейджем: зелёный — успех, красный — ошибка, серый «Not checked» — подключение ещё не проверялось.
Глубина проверки зависит от провайдера: для GitLab проверяются токен, версия сервера и доступные проекты; для большинства остальных — только доступность хоста, учётные данные при этом не проверяются (об этом говорит текст результата).
Вебхук подключения
Вебхук — основной способ, которым DoQA узнаёт о завершении пайплайна; без него статус доедет только поллингом, с задержкой (см. жизненный цикл пайплайна). Карточка подключения показывает готовый адрес вебхука с кнопкой копирования — настройте в CI-системе отправку событий пайплайна на этот адрес.
Подлинность вебхука проверяется секретом из поля «Секрет вебхука»: в GitLab тот же секрет указывается в поле «Secret token» настроек вебхука, у остальных провайдеров тело запроса должно быть подписано HMAC-SHA256 этим секретом. Если секрет в подключении не задан, входящие вебхуки отвергаются.
Привязка CI-проектов
Второй шаг той же секции — привязка репозиториев (CI-проектов) к пространству. Если подключений несколько, сначала выберите подключение. Каждая строка привязки:
- «Repository» — репозиторий; поиск подсказывает варианты начиная с 2 введённых символов;
- «Name» — человекочитаемая метка привязки, необязательна;
- «Subproject identifier» — необязательный идентификатор подпроекта.
Пара «репозиторий + идентификатор подпроекта» должна быть уникальна. Две строки с одним репозиторием и разными идентификаторами — это два раздельных источника автотестов: в каталоге автотестов они видны как разные источники, а идентификатор передаётся в пайплайн переменной DOQA_SOURCE_KEY (см. переменные пайплайна). Сохранение — кнопкой или сочетанием Ctrl/Cmd+S.
Основная ветка
На карточке подключения, в блоке «Default branches of linked projects», по каждому привязанному проекту можно задать основную ветку. Значение сохраняется по Enter или при уходе из поля; пустое поле сбрасывает настройку.
Основная ветка используется как ветка по умолчанию в формах запуска, когда у выбранных автотестов ещё нет истории запусков — подробнее в пресетах запуска.
Вид нативного фильтра
Селект «Native filter template» на карточке подключения задаёт вид нативного фильтра тестов: «Auto-detect» либо один из восьми видов — surefire, gradle, pytest, gotest, playwright, phpunit, dotnet, jest. Заданный вид действует на все привязки подключения и имеет высший приоритет в цепочке определения фильтра. Что такое нативный фильтр и как он влияет на запуск — Нативный фильтр тестов.
Авто-настройка переменных в CI-проекте
У каждой сохранённой привязки есть кнопка «Настроить CI/CD Variables». DoQA создаёт или обновляет в CI-проекте ровно три переменные:
DOQA_URL— адрес вашего экземпляра DoQA;DOQA_TOKEN— project-токен (создаётся автоматически, переменная маскируется);DOQA_SPACE_ID— ID пространства.
После этого раннеру не нужно настраивать эти переменные вручную, чтобы обращаться к API DoQA — запрашивать тест-план и отправлять результаты.
Что важно знать:
- запись переменных поддерживается только для GitLab; для остальных провайдеров DoQA сообщит, что операция не поддерживается, и переменные придётся завести вручную;
- переменные пишутся токеном самого подключения — в проекте GitLab ему нужна роль Maintainer или выше; при нехватке прав DoQA покажет отдельную ошибку;
- перед записью в CI-систему запрашивается подтверждение.
Project-токен
Project-токен — API-токен проекта DoQA. Им аутентифицируются запросы, которые пайплайн делает к DoQA без логина и пароля: тест-план, проверка критериев приёмки, отправка результатов, а также Autotest API адаптеров. Токен действует на все пространства проекта.
Как создать токен — Создание API-токена. Авто-настройка переменных создаёт и подставляет project-токен в CI-проект сама.
Смотрите также
- Запуск автотестов из DoQA — способы запуска, переменные пайплайна, жизненный цикл
- Автоматика запусков — расписания, авто-ретрай, критерии приёмки прогона
- Интеграции с CI/CD — общие подключения на уровне тенанта
- Отправка результатов автотестов — доставка готовых отчётов без запуска из DoQA