Три способа реализовать кросспроектный триггер джобы с поправкой на права

Привет, Хабр! Меня зовут Женя, я SDET в «Островке». Каждый день я помогаю командам внедрять автотесты — от сетапа проекта до код-ревью. Сегодня хочу рассказать, как мы бились над кросспроектными джобами и что из этого вышло.

Спойлер: финальное решение оказалось элегантным, но давайте по порядку.

Нативный тригер - просто, но не гибко

Для начала обратимся к нативному тригеру gitlab, который выглядит довольно просто:

trigger_autotests:
  stage: autotests
  trigger:
    project: $PROJECT_RELATIVE_URL
    branch: $AUTOTESTS_BRANCH
  variables: 
    BASE_HOST: https://$CI_COMMIT_REF_SLUG-$CI_PROJECT_NAME.p.ostrovok.ru # любая значимая переменная

Скорее всего при запуске пайплайна с такой джобой вы увидите ошибку 403 Forbidden, причем причина падения видна только при наведении курсора тк в джобу провалиться нельзя

Чтобы решить проблему, необходимо добавить каждого разработчика в Members целевого проекта с ролью Developer, но если команда большая, это превращается в рутину. Групповые права не работают — CI_JOB_TOKEN привязан к конкретному пользователю. Прокинуть системный токен тоже не получится — этот функционал пока в обсуждении (ссылка).

Api-тригер - обходим ограничения

Более гибкий вариант:

1. Берём токен из Settings → CI/CD → Pipeline triggers в проекте с тестами

2. Сохраняем его в переменные основного проекта как DOWNSTREAM_TOKEN

3. Используем в джобе:

trigger_autotests:
  stage: autotests
  tags: 
    - runner-type:shell
  script:
    - >
      curl -X POST
      -F token=$DOWNSTREAM_TOKEN
      -F ref=$AUTOTESTS_BRANCH
      -F "variables[BASE_HOST]=https://$CI_COMMIT_REF_SLUG-$CI_PROJECT_NAME.p.ostrovok.ru" # любая значимая переменная
      "https://gitlab.ostrovok.ru/api/v4/projects/$DOWNSTREAM_PROJECT_ID/trigger/pipeline"

Запускаем и радуемся, что джоба не упала из-за отсутствия прав. Но такая джоба не упадет, даже если упадут тесты, ведь для GitLab главное — что POST-запрос отработал. Никакой визуализации дочернего пайплайна не будет, так что тестировщикам приходится вручную отслеживать результаты.

Вот и получается дилемма: либо раздавать права, либо мириться с невидимыми тестами. Либо...

Наше решение - тесты в Docker-образе

autotests:
  stage: autotests
  image: $AUTOTESTS_IMAGE
  tags:
    - runner-type:qa-selenium-docker
  script:
    - cd /opt 
    - pytest ... # любая ваша команда с тестами

Казалось бы, решение идеальное — но и здесь есть два подводных камня, о которых лучше знать заранее:

1) GitLab по умолчанию монтирует проект в /builds/<namespace>/<project>, полностью игнорируя WORKDIR из Dockerfile. Если не сделать cd в нужную директорию (у нас это /opt/tests), pytest просто не найдёт тесты, и вы получите загадочное "No tests found".

2) Права доступа — снова они! Стандартный раннер отказывался удалять pycache после тестов, поэтому все новые джобы падали с ошибками. Решили переключением на qa-runner, который работает в привилегированном режиме (privileged: true) — это даёт ему права на удаление системных файлов вроде pycache.

Выводы: какой способ выбрать

• Нативный триггер — если команды маленькие и права не проблема

• API-триггер — когда важно обойти ограничения, а мониторить тесты вручную — норма

• Docker-образ — универсальное решение, которое подходит почти для всех случаев

Всем зеленых пайплайнов!