Переезд с include на GitLab CI Components: у модуля появляется объявленный spec: inputs с типами и дефолтами, а опечатка в имени input роняет пайплайн до старта… Как переезжали
Потрясающий выпуск GitLab 12.2 поможет командам оптимизировать пайплайны, расширить возможности совместной работы и управлять взаимозависимостями между проектами. Подробности ниже. Более быстрые и гибкие пайплайны Пайплайны CI нужны для автоматизации задач сборки и тестирования,
Копипаст .gitlab-ci.yml по десяткам сервисов привел к config drift: пайплайны расходились, а правка одной строчки требовала 10+ MR. Вынесли логику CI в отдельный репозиторий модулей, подключаемых через include с версионированием по SemVer — в проекте остается только короткий файл с переменными. В итоге миграция с Kaniko на BuildKit заняла 5 дней вместо 2-3 недель, а типовой багфикс на 20 сервисах — 1 час вместо 11. Смотреть, как устроены модули ->
Ходит легенда, что однажды разработчики GitLab закупились шапками, сделанными из переработанных крышечек от бутылок. И их настолько вдохновила идея повторного использования, что они решили добавить такую возможность и в свой продукт. Подкрепив это всё стандартизацией CI, они представили комьюнити новый механизм — GitLab CI/CD components.В этой статье я хочу рассказать Хабру, для чего вообще нужны компоненты, как ими пользоваться и где использовать. Читать далее