GG
это один из вариантов. либо всегда в оконечном gitlab-ci можно переопределить части YAML словарей
Size: a a a
2019 November 27
ВГ
Dmitry K.
Я немного не понимаю как при таком подходе можно решать некоторые кейсы без шаблонизации с кондишнлами. Например в 10 проектах у меня в билд джобе kaniko с одними флагами билдит, а двум другим нужны свои особенные флаги.
Через переменные?
ВГ
я бы через переменные окружения разрулил, а потом в инклюд файле в пайплайне по ним переключал разные ветки выполнения
+
2019 November 28
Д☆
Dmitry K.
Господа, а кто как управляет .gitlab-ci.yml из одного места? У меня в проекте количество сервисов растёт, декларация для CI/CD у каждого сервиса практически одинаковая за некоторыми нюансами. Смотрю в сторону сабмодулей, какой-нибудь самодельной шаблонизации из разряда
if project_name = 'xxx'; do smth; end и https://docs.gitlab.com/ce/ci/yaml/#include, но пока плохо представляю как это всё склеить вместе. Может кто-нибудь поделиться своими best practices? :)jinja2 отличный шаблонизатор
BG
Dmitry K.
Господа, а кто как управляет .gitlab-ci.yml из одного места? У меня в проекте количество сервисов растёт, декларация для CI/CD у каждого сервиса практически одинаковая за некоторыми нюансами. Смотрю в сторону сабмодулей, какой-нибудь самодельной шаблонизации из разряда
if project_name = 'xxx'; do smth; end и https://docs.gitlab.com/ce/ci/yaml/#include, но пока плохо представляю как это всё склеить вместе. Может кто-нибудь поделиться своими best practices? :)Include базовый + миксиновые + настройка через переменные окружения + скрипты на питоне для сложных случаев.
Еще есть вариант дергать команду из Makefile проекта, типа
Еще есть вариант дергать команду из Makefile проекта, типа
make lint, а там уже внутри все правильноA
это один из вариантов. либо всегда в оконечном gitlab-ci можно переопределить части YAML словарей
НЯП нельзя, раньше, вроде, ругался на конфликтующие ключи.
GG
Include базовый + миксиновые + настройка через переменные окружения + скрипты на питоне для сложных случаев.
Еще есть вариант дергать команду из Makefile проекта, типа
Еще есть вариант дергать команду из Makefile проекта, типа
make lint, а там уже внутри все правильнонасчет make lint очень интересный вопрос
GG
с одной стороны - мы имеем одинаковость пайплайна и возможность запускать команду у разраба вручную
GG
с другой - мы отдаем часть пайплайна разрабу, что несет с собой неиллюзорные риски, что он его сломает или скомпрометирует
GG
в общем, я пока единой позиции как лучше делать не сформировал... И, да, у вас есть еще локальная разработка? Тогда мы идем к вам )
A
Include базовый + миксиновые + настройка через переменные окружения + скрипты на питоне для сложных случаев.
Еще есть вариант дергать команду из Makefile проекта, типа
Еще есть вариант дергать команду из Makefile проекта, типа
make lint, а там уже внутри все правильноПредлагаю сразу
cpp -D... template.h | sh -s
:)BG
с другой - мы отдаем часть пайплайна разрабу, что несет с собой неиллюзорные риски, что он его сломает или скомпрометирует
У нас тут вроде DevOps канал, мне казалось, отдать часть работ разрабу, а еще унифицировать линты на сервере и локально как раз и есть часть идеи, нет?
A
Alexander
Предлагаю сразу
cpp -D... template.h | sh -s
:)Ну или m4, если нужны циклы.
PD
Народ привет. Вопрос есть. Это важно. Короче есть много разных гуишных приложений для просмотров логов( истории коммитов ) и более детальную инфу по максимуму о каждом из них, но если бы был спор конкретно какое лучше гуишное приложение для вывода/просмотра истории коммитов ( вместо манипуляций с командой git log в терминале ) именно между двумя вариантами ( третьего не дано ), то какое из них лучше: gitk или gitKraken ?
ребята привет. Сорри, если вопрос попахивает флудом, но учитывая то, что я попробовал tig она оказалось консольной, а консольные приложения даже если они гуишные мне не очень нравятся, так как они как правило не удобные. Поэтому те, каждый из которых имел разные гуишки для просмотра истории коммитов в git-е вместо извращений с git log, плиз ответьте мне на тот вопрос, что я реплею
GG
У нас тут вроде DevOps канал, мне казалось, отдать часть работ разрабу, а еще унифицировать линты на сервере и локально как раз и есть часть идеи, нет?
понимаешь... есть КОДЕРЫ, а есть РАЗРАБЫ
GG
надо разницу пояснять?
BG
Alexander
Предлагаю сразу
cpp -D... template.h | sh -s
:)А template.h вытягивать из общей репы? Там 98% pipeline дублироватся будет)
BG
понимаешь... есть КОДЕРЫ, а есть РАЗРАБЫ
Ну, мне повезло, у меня еще ни разу не ломали pipeline, максимум доправляли за мной косяки :)
GG
ну, и вся проблема в том, что кейсы очень разные. В принципе, невозможно засунуть всю разработку в гитлаб и чтоб локально не прогать