Comments 17
Спасибо за статью, некоторые штуки не знал. Однако модульность и гибкость могут привести к противоположному эффекту - никто кроме GitLab и Ops экспертов не понимает эффективный конфиг. Мы в конторе запретили метапрограммирование пайплайнов - пусть будет на сотню строк больше но просто и декларативно.
У нас подключаемый темплейт на сотни строк, а в каждом проекте лежит gitlab-ci.yaml только с нужными для разрабов переменным. Залог того, что никто не накосячит в ci
Ага, а когда у тебя несколько сотен проектов в гитлабе, в каждом проекте миллион веток и тебе надо сделать правки, например вынести что-то в переменные окружения, вот веселуха будет. И я уже не говорю что при таком подходе никакой стандартизации между проектами быть не может, каждый проект как снежинка становится уникален и по возвращению приходится погружаться каждый раз заново.
Сложность вопрос компетенции, а компетенции - обязанностей. Если никто кроме девопсов не должен вникать в это, зачем так усложнять всем жизнь и плодить копипасты и кучу лишней работы на ровном месте?
Грамотно спроектированный гитлаб си шаблон держит энтропию на контроле, позволяет оркестрировать сотней проектов минимальным количеством специалистов, доставлять ci фичи в самые короткие сроки, а самое главное позволяет тестировать пайплайны перед их подключением
И после всего этого кто ещё будет утверждать, что Jenkins это сложно и не понятно. Смотрю вот на все это и радуюсь, что не пользуюсь gitlab ci. Имхо
И ни слова про gitlab ci components...
Крутая подборка фич.
У меня только вопрос - есть ли какой-то вменяемый способ дебажить пайплайн в принципе. Ну и особенно со всеми вложениями вроде variables/include/etc? Или я правильно понял, что ничего особенно хорошего для этой проблемы нет?
Спасибо за материал. Многими штуками пользовался и пользуюсь. Считаю, что чем проще сделано - тем лучше. Отлаживать эти пайпы то ещё удовольствие, особенно когда они тиражируются на кучу проектов.
Когда я сам делал типовой пайп для приложений, старался сделать стандартную и понятную всем коллегам историю с минимум сложностей. Но даже в этом случае, спустя пару лет, когда заходишь посмотреть и думаешь: блин, а как оно там было и зачем... Без документации ещё не всегда вспомнишь почему так или иначе в каком-то месте реализовано. Впрочем, как и везде)
Cпасибо, весьма полезно
так и не понял, нафига нужны дочерние пайплайны. Разве нельзя просто запустить их последовательно?
Дочерний может быть пайплайном другого проекта, например.
В репо с кодом -- собрал проект, потом джобой дернул другой проект с его деплоем.
Или ещё пример. Репо с contract-first спекой и репо с зависимым от неё проектом :)
Главный пайпы в корне проекта, а вот его дочерние это например api и rabbitmq, запускаются вместе, но можно и раздельно если надо. Депсов может быть много, rabbitmq, redis, redis-insight, db - каждому свой пайп, и все объединены
Поставил плюс, чтоб немного компенсировать страдания.
С CI гитлаба самая веселуха - это не синтаксис, а семантика. С тем, чтобы скрипты скомпоновать, проблем нет, а вот как заставить гитлаб делать всё так, как тебе требуется - это надо постараться.
Просто надо понимать, что с одной стороны гитлаб уже старый проект сам по себе, в нём много легаси, новые фичи иногда реализуются с оглядкой на старые ограничения, и часто являются затычками, чтобы обойти их. Например, extends вводили как раз чтобы решить проблемы якорей. А во-вторых, им всё-таки приходится развиваться с оглядкой на весь опыт его использования комьюнити, чтобы за раз ничего слишком много не поломать :)
А зачем делать <code class="language-yaml”>, если можно ```yaml?
Красивый GitLab CI: extends, якоря, include, trigger