📎 Компоненты были представлены в GitLab 16.0 как экспериментальная функция, а в версии 17.0 стали общедоступными. Механика похожа на модули в Terraform или пакеты в языках программирования.
✅ Зачем это нужно?
— Избежать дублирования кода: Устранить копирование одинаковых jobs и steps в разные
.gitlab-ci.yml файлы.— Стандартизировать процессы: Создать единые, проверенные шаблоны для часто выполняемых задач (сборка, тестирование, деплой).
— Упростить поддержку: Обновить логику в одном месте (компоненте), и изменения применятся во всех проектах, которые его используют.
— Создавать библиотеки шагов: Делиться готовыми решениями внутри команды или сообщества.
✅ Ключевые принципы:
🔵Компонент — это файл
.yml с определением одной или нескольких джоб, который хранится в отдельном репозитории GitLab.🔵Include — Подключение компонента в
.gitlab-ci.yml с помощью директивы include: component.🔵Параметры — Компоненты принимают входные параметры (inputs), что делает их гибкими и адаптируемыми.
✅ Практический пример:
Простой компонент для линтера (
.gitlab/ci/components/linter.yml в отдельном репозитории)
# Определение компонента
spec:
inputs:
stage:
default: test
image:
default: "node:20-alpine"
"lint-$[[ inputs.linter ]]": # Динамическое имя джобы
stage: $[[ inputs.stage ]]
image: $[[ inputs.image ]]
script:
- run-lint --linter $[[ inputs.linter ]]
Использование компонента в проекте:
# .gitlab-ci.yml вашего приложения
include:
# Указываем полный путь к компоненту
- component: gitlab.example.com/org/ci-catalog/linter@main
inputs:
linter: "eslint"
GitLab CI Components — это эволюция подхода к CI/CD как к коду. Они позволяют заменить рутинное копирование десятков строк конфигурации в каждом проекте на подключение готового компонента. В результате CI/CD-конфигурация превращается из монолитного скрипта в набор декларативных, версионируемых и легко тестируемых модулей.
➡️ Подробнее в документации Gitlab
#заметкиИнженера