Сборка проектов с GitLab CI: один .gitlab-ci.yml для сотни приложений

[SlavikF]

Возникает чувство, что статья написана несколько абстрактно. Может быть стоило вначале более чётко обозначить проблему, которую вы пытались решить? А то возникает подозрение, что здесь приведён список костылей для конкретной ситуации и не совсем понятно, что я могу взять из этого для себя.

[diafour]

Есть сотня проектов, у которых один и тот же .gitlab-ci.yml, Dappfile и папка с helm chart-ом. Задача — обновлять эти файлы, желательно из одного репозитория.
На практике это может быть что угодно, лишь бы этого много и не хотелось бегать по репозиториям, обновлять файлы. Например, статические сайты на jekyll, собираемые в docker-образ (сайты правят отдельные команды, за сборку отвечает одна команда). Внутренние java-библиотеки, собираемые в jar-артефакты, да вообще любые компоненты, которые не требуют индивидуальных правил сборки (тоже самое — компоненты правят разные люди, сборкой занимается одна команда).

[scor2k]

Что бы не запускать сборку надо в сообщении к коммиту написать в любом месте “[CI SKIP]”. Это, по-моему, немного проще :)

[diafour]

Это уже вопрос требований в конкретной задаче. Дело в том, что по коммиту с [CI SKIP] pipeline создаётся без задач. Поэтому, чтобы запустить сборку с новой конфигурацией, потребуется, например, добавить новый коммит или подмёржить master в ветку release — повторюсь, всё зависит от требований и от принятого на проекте процесса внесения изменений.

P.S. Навесить тэг на прилетевший коммит с [ci skip] — не вариант, pipeline тоже будет пустой.

Pipelines

[allburov]

Интересное решение, как раз сейчас изучаем возможности gitlab-ci, чтобы переехать на него.
Верно понимаю, что разработка идёт в мастер-ветках и новый yml коммитится именно туда?

[diafour]

В проекте, для которого создавалось решение — да, достаточно коммита в master, а из него cherry-pick в feature-ветку.
Если проекты не совсем однотипны, есть отклонения, то можно в переменных проекта указывать особенности, а в distribute.sh получать переменные через API: https://docs.gitlab.com/ce/api/project_level_variables.html
Например, где-то нужно в master сделать коммит, а где-то в develop.

[gecube]

Ура. Наконец-то можно считать историю с зависимостями между разными .gitlab-ci.yaml файлами завершенной. Есть два прекрасный ключевых слова: include и extends, которые эту задачу должны брать на себя

docs.gitlab.com/ee/ci/yaml/#include

Introduced in GitLab Edition Premium 10.5. Available for Starter, Premium and Ultimate versions since 10.6. Behaviour expanded in GitLab 10.8 to allow more flexible overriding. Available for Libre since 11.4

Using the include keyword, you can allow the inclusion of external YAML files.

docs.gitlab.com/ee/ci/yaml/#extends

Introduced in GitLab 11.3.

extends defines an entry name that a job that uses extends is going to inherit from.