Comments 13
В общем случае не надо это делать, просто не надо. Экономия на сотне строчек выливается потом в полную нечитаемость конфигов ci/cd, невозможность их оперативной правки, и разрастанию костыльной базы "ну тут не можем опцию сборки добавить, пайп стандартный править нельзя, пропиши в Makefile ручками и потом не забудь при мерже". Я молчу о том, что чтобы понять что тут происходит, надо открыть десяток файлов с инклудами, страничку с переменными, и мержить это поделие сумрачного гения в уме... Не нужна дедупликация на таких крохотных обьемах кода. А если у вас ci\cd в одной репе в пару десятков тысяч строк - вы что-то делаете не так.
Да, есть кейсы, в которых инклуды полезны, например типовой пуш артефакта, но это именно что отдельные случаи, каждый из которых надо смотреть под лупой, прежде чем выносить в компонент.
Решение о применении GitLab Components зависит от контекста. В небольших командах с парой проектов и простыми пайплайнами избыточная абстракция может создать больше проблем, чем решить, это правда. Но мой опыт показывает, что типовые задачи встречаются в большинстве проектов, и их стандартизация приносит пользу. Что касается читаемости - имхо ключевую роль тут играет качество документации и именования. Хорошо спроектированные компоненты с понятными интерфейсами могут наоборот упростить понимание пайплайна, скрыв сложную логику за простым API.
Компоненты - это инструмент, и как и любой инструмент, его нужно применять осознанно, а не ради самого инструмента.
Переиспользование через библиотеку это палка о двух концах. И те кто топит за и те кто против неправы в абстрактном контексте.
Плюсую из личной практики. Это превращается в нечитаемое нечто и все эти "оптимизаторы" пайплайнов часто блокируют работу большого количества команд. Особенно когда это разрослось на несколько команд разработки и в CI принесли "симпл фикс" в один из компонентов/шаблонов.
Было бы неплохо сравнить с другими сервисами. Пользовался таким на GitHub несколько лет назад.
И при этом кто-то ещё говорит, что Дженкинс мёртв??? Да он в купе с шаред либами выигрывает и в юзабилити и в читаемости.
Не совсем понял из статьи, какую проблему решают компоненты. Чем они лучше hidden jobs + extends, из которых собирается универсальный пайплайн? Поясните, пожалуйста.
Компоненты решают проблему переиспользования кусков конфигурации в разных репозиториях.
hidden jobs + extends, увы, довольно хрупкая конструкция, не дающая тонко настраивать себя, поскольку структура extends-джобы должна повторять структуру скрытой джобы. В итоге как раз и получается ситуация, на которую жаловались выше - при обновлении репы с шаблонами слетает сборка всех проектов сразу.
Компоненты же можно настраивать через инпуты вместо переопределения, что открывает возможность безопасной оптимизации пайплайна.
Прошу прощения за неспособность сходу осознать, но мне нужен пример. Сам-то я ненастоящий сварщик, а .NET-разраб, которому волею судеб пришлось заняться легким девопсом) И хочется понять, переделывать ли наш CI.
Допустим есть общий пайплайн в отдельном репозитории. Его инклудят сотня реп с сервисами, их gitlab ci - по сути указание некоторых переменных, в зависимости от нужд сервиса. В общем пайплайне рулы, тоже какие то переменные и куча инклуды с джобами. Сами джобы поделены на файлы в зависимости от окружения, куда идет деплой. И тоже по сути extend-ят hidden джобы, настраивая их переменными уже в зависимости от среды развертывания.
Буду признателен, если поясните, что тут лучше заменить на компоненты)
GitLab CI/CD components: повторно используемый CI как путь к чистому и здоровому GitLab