Как стать автором
Обновить

Комментарии 12

Как при таком подходе запустить N параллельных пайплайнов для сборки N образов?

Зависит от вашей фантазии и потребностей. В GitLab есть parallel для одновременного запуска нескольких джобов внутри одного пайплайна.

В Jenkins есть shared lib, где ты можешь хранить переиспользуемый код любого уровня. В Github actions есть action'ы. В Gitlab почему-то до сих пор нет ничего подобного =(.

А чем собственно это отличается от создания проекта для всех переиспользуемых CI шаблонов и подгрузкой их через include?

`include` подгружает только `gitlab-ci.yml` файлы. Тут речь о том, чтобы подгружать отдельные скрипты (да и вообще любые файлы из другого репозитория)
А чем собственно это отличается от создания проекта для всех переиспользуемых CI шаблонов и подгрузкой их через include?

Тем что это совсем про другое. В jenkins и github actions вы реализуете библиотеку методов на groovy и javascript соотвественно, которые потом используйте в своих пайплайнах как обычные стандартные методы. А в gitlab по сути нет ничего кроме script.


Нечто подобное и пытался сделать автор поста в gitlab. Но поскольку gitlab не имеет никакого способа расширять и добавлять новые методы к его стандартным https://docs.gitlab.com/ee/ci/yaml/#job-keywords, поэтому так все печально и выглядит. И все на баше естественно, так как иначе придется таскать в раннеры зависимости для своего "библиотечного кода".

В некоторых сценариях, как не изощряйся с include и when/only, всё равно GitLab CI не позволит достичь достаточной гибкости. В паре проектов подходящим решением оказалось использование Dynamic child pipelines, где в parent на основе некоторой логики динамически генерируем .gitlab-ci.yml, и тут же триггерим его исполнение в child.

when/only синтаксис по большому уже депрекейтнули.
Rules дают куда больше гибкости

Смотрели ли в сторону !reference tags? Запустил ваш фреймворк, но что-то не получилось пошарить .sh файл между репозиториями(

Да, но они всё равно не позволяют вынести код из gitlab-ci. А когда его много - это не удобно.

Если напишете подробности, могу попробовать подсказать, что не запустилось.

Попозже, сейчас тыкаюсь с референцами и якорями, должно быть оно

Если якоря действительно можно внедрить в script - можно будет и в отдельные файлы вынести кмк. Еще экспериментирую, позже напишу, если понадобиться помощь) Спасибо!

Нашел решение - якоря

Их можно вставить в script, а алиас(-ы) для якоря можно выносить в отдельные .yml файлы и includить их по необходимости. Работает кроссрепозиторно, мне нравится) За фреймворк все равно спасибо, было интересно покопаться/позапускаться

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории