Comments 9
очень странная статья.
Первое. Очень странно сравнивать дженкинс и GitlabCI. У первого действительно очень богатые возможности по кастомизации и рисованию UI, которые гитлаб даже не снились. У меня была задача предоставить разработчикам минимальную UI с элементов выбора (например, комбобокс) или валидацией параметров. На гитлабе в текущем виде это сделать попросту невозможно. Для этого надо пилить внешний интерфейс - будь то flask какой, или притаскивать полноценные оркестраторы задач вроде rundeck/polemarch. Увы. Но при этом под капотом легко может быть гитлаб, потому что через АПИ он практически безгранично расширяется
Второе. Очень странно упоминать мультипайплайн. Позвольте поинтересоваться, у вас там платная редакция гитлаба? Или все-таки бесплатная? Потому что если второе - это постоянный бег с препятствиями. Например, триггернуть пайплайн можно, но в виде единого интерфейса увидеть мультипайплайн нельзя. Может быть сейчас ситуация изменилась, т.к. постоянно какие-то фичи из платной версии переезжают в CE, но буквально недавно это было так. Еще отдельная мякотка - это синхронизация разных пайплайнов. Буквально недавно опять же надо было в цикле ждать выполнение дочернего пайплайна, чтобы вытащить из него артефакты. Тут целый простор для получения race condition...
Целью не ставилось сравнивать Jenkins vs Gitlab CI. Была рассмотрена реализация конкретного кейса, которая кстати оказалась не так проста как первоначально ожидалось.
Целью не ставилось сравнивать Jenkins vs Gitlab CI.
тем не менее, Вы вольно или невольно сравнили эти оба продукта, я только расширил и указал на определенные недостатки гитлаба, что возможно позволит кому-то в дальнейшем принять правильное решение, что внедрять в свой ландшафт
В остальном решение показалось переусложненным. Зачем надо было разбивать на столько много шагов? Достаточно было в самом шаге теста проверить файл с фикстурами и принять решение для запуска кафки. Но тут непонятно что все эти YML делают - может Вы в какую-то внешнюю систему ходите и там тестовый стенд поднимаете, мало деталей, примеров Вы не выложили, а только конкретные сниппеты
Еще важный вопрос не поднят - вопрос ролевой модели Гитлаба. Насколько я помню, разработчик должен иметь доступ к репозиторию, в который делается include, иначе пайплайн не сможет нормально стартануть и упадет (но это надо тоже проверить еще раз). Что я могу сказать - хорошо быть админом и не иметь этих проблем...
а есть какая хорошая статья на русском как через это дело gitlab cicd работать с docker compose ?
зачем? Задача какая? Вообще мне лично хватило официальной доки гитлаба.
А все не оч сложно. Собираете что вам нужно, а потом пушите что хотите в registry. Потом оттуда качаете по токену.
Пытался реализовать подобное.
job:
stage: some-stage
image: docker/compose
services:
- docker:19.03.12-dind
variables:
COMPOSE_PROJECT_NAME: docker-compose-demonstrator-$CI_JOB_ID
DOCKER_DRIVER: overlay2
DOCKER_HOST: tcp://docker:2375
before_script:
- docker-compose -f ....
- CONTAINER_IP=$(route -n | awk '/UG[ \t]/{print $2}')
- echo ${COMPOSE_PROJECT_NAME}_default
....
script:
- docker ps
- docker network list
- echo $CONTAINER_IP
....
after_script:
- docker-compose logs || true
- docker network disconnect ${COMPOSE_PROJECT_NAME}_default $CONTAINER_ID || true
- docker-compose down || true
....Я не занимаюсь девопсом, но хотелось попробовать поднять проект и запустить на нем е2е тесты, результат в целом устроил:)
От прочитанного у меня возникает ощущение, что вы городите костыли:
– На уровне gitlab-ci не должно быть проверок переменных, сохраненных в коде. Если вам хочется управлять переменными в коде (что странно, но ладно), тогда пусть сама утилита запуска тестов проверяет этот флаг.
– Если же вы просто хотите формировать разный пайплайн, то вопрос: от чего он зависит? Почему в одном случае мы запускаем тесты с кафкой, а в другом без нее? Может быть дело в стейдж-ветках: дев / тест / релиз? Если так, то посто определите набор джоб и для каждой ветки определи какие джобы выполнять.
– Для доступа к api из скриптов нет необходимости использвоать свой токен, для джоб есть: $CI_JOB_TOKEN
– И вообще вопрос: а нужен ли тут вам родительский/дочерний пайплайн? Может быть вы просто хотите запустить джобы параллельно?
Благодарю за агрументированный разбор.
Теоретически если оба сценария завернуть в один то можно обойтись без мультипайплайна, но одним из условий реализации было развести сценарии тестирования по разным yaml файлам
Целью было покрыть общим cicd более 20 spark проектов, к которым применяется либо один либо другой сценарий и список сценариев тестирования может расширяться
Здесь согласен с вами, собираюсь переключиться на $CI_JOB_TOKEN
Параллельно запускать в данной реализации нельзя потому как job в родитеском пайплайне ждет результата тестирования в пайплайне ребенке.
Gitlab CI «Smart» Pipeline: родители и дети