Итак, пытаюсь добить задачу:
В разрабовском проекте на определенном этапе прохождения пайплайна вызвать через хуки/триггер/магию другой пайплайн с тестами и дождаться их работы. После этого нужно покраснеть, если тесты упали или позеленеть, если они прошли.
Понятное дело, мы можем покраснеть ещё раньше.
Моя предыдущая история закончилась на том, что я создал дополнительный stage, в котором курлом дёргается тригер, навешенный на тестирующий проект.
При этом текущий пайплайн считает свою задачу выполненной и заканчивает работу, зеленея. Как там отработали тесты, ему пофиг.
После недолгого изучения документации на гитлабе, я нашел почти решение проблемы.
Мой прошлый скрипт выглядел вот так:
script:
- apk --no-cache add curl
- curl -X POST -F token="$TEST_TOKEN" -F ref=master https://gitlab.com/api/v4/projects/NNNNNN/trigger/pipeline
Для того, чтобы "связать" два пайплайна используется магия в виде $CI_JOB_TOKEN
Почитать об этом можно здесь.
Текущий вариант куска CI:
trigger_tests:
stage: test
script:
- apk --no-cache add curl
- curl -X POST -F token="$CI_JOB_TOKEN" -F ref=master https://gitlab.com/api/v4/projects/NNNNNN/trigger/pipeline
environment: staging
only:
- master
В разрабовском проекте на определенном этапе прохождения пайплайна вызвать через хуки/триггер/магию другой пайплайн с тестами и дождаться их работы. После этого нужно покраснеть, если тесты упали или позеленеть, если они прошли.
Понятное дело, мы можем покраснеть ещё раньше.
Моя предыдущая история закончилась на том, что я создал дополнительный stage, в котором курлом дёргается тригер, навешенный на тестирующий проект.
При этом текущий пайплайн считает свою задачу выполненной и заканчивает работу, зеленея. Как там отработали тесты, ему пофиг.
После недолгого изучения документации на гитлабе, я нашел почти решение проблемы.
Мой прошлый скрипт выглядел вот так:
script:
- apk --no-cache add curl
- curl -X POST -F token="$TEST_TOKEN" -F ref=master https://gitlab.com/api/v4/projects/NNNNNN/trigger/pipeline
Для того, чтобы "связать" два пайплайна используется магия в виде $CI_JOB_TOKEN
Почитать об этом можно здесь.
Текущий вариант куска CI:
trigger_tests:
stage: test
script:
- apk --no-cache add curl
- curl -X POST -F token="$CI_JOB_TOKEN" -F ref=master https://gitlab.com/api/v4/projects/NNNNNN/trigger/pipeline
environment: staging
only:
- master
И что это дало?
На первый взгляд - ничего. Всё тот же зеленый passed, но при тычке на него появляется красивый пайплайн граф, на котором появился столбец Downstream. В нём-то и отображается результат работы "дёрнутого" пайплайна.
На первый взгляд - ничего. Всё тот же зеленый passed, но при тычке на него появляется красивый пайплайн граф, на котором появился столбец Downstream. В нём-то и отображается результат работы "дёрнутого" пайплайна.
Суммаризируя
Результат как бы получен, но он стрёмный. В списке выполненных пайплайнов результат залёный. Чтобы увидеть результат тестов нужно ткнуть на него у посмотреть результат в столбце Downstream - он может быть красным.
Как лечить?
Навскидку, на той же странице, где описан CI_JOB_TOKEN, есть опция - скачать по апи артефакты с downstream пайплайна. Можно скачать, добавить этап, проверяющий наличие файла. Если файл будет найден - всё гуд, если нет - падать.
Решение какое-то напряжное. Отложу его реализацию, вдруг найду что-то другое.
Результат как бы получен, но он стрёмный. В списке выполненных пайплайнов результат залёный. Чтобы увидеть результат тестов нужно ткнуть на него у посмотреть результат в столбце Downstream - он может быть красным.
Как лечить?
Навскидку, на той же странице, где описан CI_JOB_TOKEN, есть опция - скачать по апи артефакты с downstream пайплайна. Можно скачать, добавить этап, проверяющий наличие файла. Если файл будет найден - всё гуд, если нет - падать.
Решение какое-то напряжное. Отложу его реализацию, вдруг найду что-то другое.
Комментариев нет:
Отправить комментарий