GITLAB CI CD сокращаем код. Gitlab ci include, extends, reference, remote, local

[@8man766]

Напишу приятный комментарий Спрашивал у chat gpt как делать темплейты - получил кукиш искал информацию в инете как делать тепмлпейты - получил ответ что только в ee версии смотрел видео бусурманов - получил какие-то тыкалки в ui, которых у меня в gitlab-ce нет Наконец то нашел видео как делать темплейты и сделал ЛАЙК

[@ГОРЕБЛОГЕР-х5к]

Четко, коротко, понятно! Ничего лишнего и с оригинальной подачей!

[@PeterCargo]

Спасибо, Антон! Задорный стиль изложения, доходчивое объяснение. Приятнее нежели документацию читать ))

[@wk7652]

Даже захотелось больше погрузиться в работу пайплайнов)) Спасибо, Антон!

[@koi-157c8]

Ко всему надо подходить из практических соображений. Если пайплайн - как рулон, то шаблоны - очевидное спасение. Но есть и обратная сторона медали. Когда есть один мелкий микросервис, а половина его пайплайнов разбросана по разным репозиториям. И вот, чтобы это все принять, приходится скакать между ними как сайгаку и смотреть откуда что берется, хотя весь пайплайн умещается на паре страниц кода с применением того же extends внутри одной репы. Еще нужно учитывать, что переменные определенные в bash'e через export, например - в before_script и script не передаются в after_script.

[@pavlenkoat]

Для этого лучше использовать репу с шаблонами. Я так и поступаю.

[@koi-157c8]

@@pavlenkoat Я немного о другом. Если приложения в группе репозиториев однотипные и не выходят за пределы группы - то да, маст хев. Но бывает так, что в одном шаблоне не получится описать все для всех, и начинают плодиться разного рода сущности вида .tempalte_mongo_sync_api_migrate_mock И все они отличаются не большими изменениями и годами не меняются. Потом начинается dependency hell. И если репозиторий не твой, а достался в наследство - то добавлять в шаблон - черевато изменениями других сервисов, о которых ты пока не знаешь. И процесс этот получается долгим и мучительным с несколькими вкладками в IDE для разных проектов и их сверкой. Я сейчас для "будущей смены" делаю так, чтобы прочитать мой пайплайн было проще. Для этого большие однотипные куски выношу в tech репу (там же, шаблоны для чартов, сборки БД с данными и тп), в той же группе проектов, а мелкие куски добавляю через extends в .gitlab-ci.yml. В одной группе может быть до десяти и больше разных проектов, которые используют tech репу. Но для других таких групп, я стараюсь делать их собственную tech репу, чтобы изменения в ней, касались только той группы проектов и никак не влили на другие проекты.

[@igancev]

Про reference не знал, спасибо!

[@pavlenkoat]

Рад что полезно

[@ВячеславБеляев-к9п]

Шикарно. Побольше бы контента по gitlab ci

[@pavlenkoat]

Да что-то просмотров мало

[@ГОРЕБЛОГЕР-х5к]

@@pavlenkoat айти тусовка ведь тоже не велика))

[@lowkeysleep]

В GitLab CI довольно удобно и гибко настраиваются паплайны. Но вот тонкости... Они как раз и заставляют "попотеть". Как пример раздел "rules" в job'е: при использовании extend и добавлении нового правила, rules из "оригинальной" job'ы затрутся. А "! reference" как-то странно сливает rules Лично выкрутился через YAML якоря А видео очень полезное! В особенности для начинающих :) Огромное спасибо за ваш контент!

[@riariorovere2462]

У меня у всех микросервисов были одинокые rules, которые зависели лишь от переменных конкретного микросервиса

[@bassmaster0983]

Приятный комментарий: Спасибо это была полезная информация, как раз этим занимаюсь, но использовал только include и extends

[@Neodim555]

Спасибо за твои ролики. Только начинаю вплывать в тему CICD эта информация очень вовремя.

[@andreykaparulin9214]

спасибо, коментарий для продвижения канала

[@Petyaumniy]

Вместо reference в script, имхо, гораздо проще использовать анчеры. Благо в секция script gitlab-ci интерпретирует вложеные листы (даже глубокой вложености) как 1 плоский лист. Таким образом подготавливаем наши атомарные кусочки конфигурации как анчоры с листом из баш кода и добавляем их анчорами в скрипт. Так же кусочки анчоров можно объединять в более высокоуровневые анчоры и так же использовать их в скрипт, гитлаб их так же пережёвывает.

[@ReflectMirage]

очень нужный плейлист gitlab ci/cd развивайте его пожалуйста, лайк!

[@pavlenkoat]

Накидал видео

[@riariorovere2462]

Ах, вот ровно день назад сам все это обнаружил. Хорошая тема для видео

[@sergo4220]

вот это годноту подвезли, автор канала просто красавчег! Темка сверхактуальная.

[@ДенисИд]

Часто используемые в скриптах команды, по возможности параметризируеммые через переменные, можно обозначить как якоря, сделать для них понятный нейминг, и потом в скрипт вставлять *имя_якоря.

[@Роман-б1ю2м]

Огромное спасибо!)

[@GushchinAndrei]

Спасибо, Антон!

[@Rixnei]

Спасибо большое за контент!

[@MrVelesko]

Знал всё кроме последнего (референс) - спасибо.

[@vshefer]

Не все понял, но мне понравилось, классный канал

[@andydrummer6310]

Спасибо за информацию. Хотелось бы узнать как для определенной задачи использовать свой образ докер, а не выкачивать с хаба

[@Lammax2012]

Спасибо!

[@alexandervoniarkha3873]

Отличный и, самое главное, понятный гайд, по неочевидной теме. Очень понравилось

[@21JackHammer]

Дженкинс юзаешь? Или ток гит?

[@pavlenkoat]

Сейчас нет, но с ним работал

[@МаксимГайдай-ъ5ж]

для справедливости стоит добавить, что экстенды делают код не только меньше, но и запутаннее. к слову, docker-compose выпилили у себя этот функционал ещё 5 лет назад, начиная с v3, не смотря на истошный вой пользователей, драма до сих пор открыта )) мотивировали это тем, что код с использованием экстендов становится очень запутанным и не поддерживаемым, но основная причина в том, что они не могут больше это поддерживать, возникает неопределённое поведение. в общем, там ребята закопались в своём коде ))

[@pavlenkoat]

Всё хорошо в меру и таблетками можно себя угробить.

[@janodenbach374]

Ты Большой Молодец ! Был бы очень признателен что бы у тебя появился какой нибудь большой курс по Bash Script от Zero 2 Hero или что то на подобие. У меня в компании мне все чаще надо писать Bash скрипты для автоматизации процессов. Например для интегральных проверок Aide или по копированию MariaDB и потом скармливания результата скрипту Nagios (который так же мне надо сделать). Хотелос бы еще раз все освежить в памяти и что бы доступным как ты умеешь языком.

[@funyfizik]

Очень интересный кейс! А главная отличная доходчивая подача

[@dagget112]

Молодец!

[@НиколайБараненко-ш6г]

годный контент, но в связи с тем что gitlab покрасился в жевто-блакитный цвет стал вопрос о целесообразности продолжения использования gitlabci...

[@АртёмНикулин-э8ш]

Как же вовремя вышло это видео. Спасибо

[@eugenechernyshenko4933]

before/script/after - списки, поэтому их нельзя расширить, их можно только смержить

[@AlexanderBukhtatyy]

Приятный или не очень комментарий! =)

[@MrLonur]

Комментарий поддрежки

[@AlexanderSavchenko91]

спасибо ) в будущем пригодится )

[@mihan1610]

все понятно объяснил

[@dmitryenot6601]

Фон огонь 🔥

[@mikhailyegorov27]

Спасибо за твой подход к объяснению) ты забавный и полезный )

[@pavlenkoat]

Я ищу баланс сейчас. Раньше юморка было больше.

[@mikhailyegorov27]

@@pavlenkoat имхо в этом видео идеальный баланс. хотя я всегда за юмор)

[@juliusmalkov9620]

Чувствую я не стану DevOps так просто(((

[@G-GIK]

Посмотрел пару видосов. Полезное есть, но слишком много лирических отступлений. Хочется вот прямо мяса, а получаешь больше макарошек)

[@pavlenkoat]

Мясо никто не смотрит. Всё любят овощи

[@frolovskii_v]

200 строк на 4 джобы это не туалетная бумага))

[@George-tt4pt]

Спасибо за видио

[@George-tt4pt]

Можно ещё добавит в пейплайн when и only = огонь .

[@pavel2392]

привет

[@jozz3235]

Firstvds Дааааа

[@ivandyk8428]

Антон после развода посвежел.

[@oleg_kishinskii]

А вот и не работает extends, слову вообще ничего из этого видео не работает заинключить темплейт получилось так: include: - project: 'INFRA/pipeline_templates' ref: master file: '/.kubernetes_deploy_template.yaml' а вот к маске привязать уже не выходит