Comments 12
Как при таком подходе запустить N параллельных пайплайнов для сборки N образов?
В Jenkins есть shared lib, где ты можешь хранить переиспользуемый код любого уровня. В Github actions есть action'ы. В Gitlab почему-то до сих пор нет ничего подобного =(.
А чем собственно это отличается от создания проекта для всех переиспользуемых CI шаблонов и подгрузкой их через include?
А чем собственно это отличается от создания проекта для всех переиспользуемых 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ить их по необходимости. Работает кроссрепозиторно, мне нравится) За фреймворк все равно спасибо, было интересно покопаться/позапускаться
Создание переиспользуемых пайплайнов для GitLab CI на bash