Адрес API-сервисов GitLab и токен пользователя, от лица которого будут осуществляться
запросы, указываются переменными среды GITLAB_API_ENDPOINT и GITLAB_API_PRIVATE_TOKEN.
Проект deployment содержит правила и настройки развёртывания сервисов в кластер, а также
конфигурационный файл, который описывает какие сервисы должны обрабатываться.
Идентификатор проекта развёртывания указывается переменной среды DEPLOYMENT_PROJECT_ID.
Если задана переменная среды MEISTER_BASE_URL, то автоматически будет производиться управление
web hook-ами в проектах. Если указана переменная MEISTER_GITLAB_HOOK_SECRET, то секрет будет
использован при установке хуков и будет проверяться при вызове.
Конфигурационный файл должен лежать в корне репозитория проекта развёртывания
и называться meister.yaml. Формат файла:
components:
component_1:
project: 12
job: package
component_2: 45где component_1 - имя компонента, значение ключа project - идентификатор проекта
в GitLab, а job - название шага, при успешном завершении которого срабатывает механизм
создания слепка версий (по умолчанию deploy). Если кроме идентификатора проекта других настроек нет, то можно использовать
сокращённую форму, как у component_2.
Создание feature-ветки в одном из отслеживаемых репозиториев приводит к созданию ветки
с аналогичным именем в deployment-репозитории, после чего components.yaml начинает обновляться
уже на конкретной ветке (а также подтягивать master-версии). Необходимо внести код из инкубатора
в этот репозиторий.
Путь до файла указывается в конфигурационном файле значением components_file, по
умолчанию это файл components.yaml в корне репозитория. Формат файла:
components:
component_1:
sha: 39f0632522c13862eff614cd48272fddc0365d2a
ref: masterгде component_1 - имя компонента, соответствует имени компонента из конфигурационного файла,
sha - SHA-номер коммита, который привёл к последней успешной сборке компонента (образы Docker
помечены этим значением), а ref - название ветки, на которой происходила сборка.