Комментарии 15
В общем случае не надо это делать, просто не надо. Экономия на сотне строчек выливается потом в полную нечитаемость конфигов 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 по сути мало чем отличаются от include: любой include можно преобразовать в компонент, просто добавив объявление spec:input.
На самом деле компоненты поддерживают и старый способ добавления через include.
Долгое время я не мог понять смысл компонентов, но он оказывается довольно простым, хотя и банальным:
а) Версионность
б) Тестируемость
С натяжкой можно добавить пункт "в) Централизованное хранение", подразумевая, что команда сначала проверит наличие готовой реализации, а уже потом напишет свою.
Компоненты - это include+. Ничего не мешает юзать компоненты так же, как и темплейты (кроме того, что темплачи в депрекейтед закинули). Как мне кажется, чаще всего параметризуют именно script. До появления компонентов можно было использовать только variables. Они, по сути, управляют поведением скрипта в рантайме - "динамика". И в целом хорошо, но разработчики решили добавить "статику"
Для меня это выглядит так, будто я всегда на JS писал var my_var, а теперь мне дали возможность написать const. Эдакое семантическое улучшение
Можно написать:
inputs.message: "Автор коммита: $CI_COMMIT_AUTHOR"
Значит сообщение будет разным для разных авторов коммита
А можно:
inputs.message: "Автор коммита: компания ООО Тмыв Денег"
Значит сообщение будет одинаковым для всех коммитов
(в обоих случаях если не переопределять script/variables или где эта штука шаблонизируется)
Итого: компонент - это просто шаблонизатор, который запускается до исполнения скриптов. Он просто вставляет нужный текст в нужные места джобы.
ИМХО: направление развития хорошее, но кажется, что хочется чего-то большего для такого шаблонизатора. Хочу иметь возможность сделать что-то типа include-multiple.inputs_array: [input1, input2, input3]. Чтобы бесконечно не копипастить инклюды или не создавать генераторы .gitlab-ci.yml (как будто если юзать генератор, то и компоненты не нужны). Есть конечно parallel.matrix, но нюанс в том, что там меняются variables, когда хотелось бы менять инпуты. Компоненты - это про контракт создания джобы, а если юзать матрицу, то тебе НУЖНО лезть в реализацию компонента, чтобы понять, какие переменные нужно прокидывать в матрице
По поводу версионирования: темплейты можно версионировать
По поводу тестируемости: для тестирования ничего не добавили с виду - тебе все так же придется писать тесты в виде отдельных джоб или в after_script'е тестируемой джобы например.
В целом, я не очень понимаю, что значит тестирование пайплайна, в доках особо ничего интересного не находил. Ради эксперимента пытался проверять компоненты на работоспособность, смотрел что выводят и запускаются ли в принципе в том же CI/CD каталоге. Вот то, что появилась структура каталога, мб интересно: есть разрабатываемый компонент: templates/<name>/template.yml. Рядом, например, можно положить templates/<name>/test.yml - использование компонента по каким-то сценариям и templates/<name>/Dockerfile.test (если например у меня компонент билдит образ).
Я сделал так: в рутовом .gitlab-ci.yml добавил инклюд test.yml при определенных условиях. Например, если я релижусь - то я запускаю вообще все тесты. А если я хочу только 1 компонент тестить, то в енвах указываю, какой. Но все равно чувства смешанные
GitLab CI/CD components: повторно используемый CI как путь к чистому и здоровому GitLab