Comments 9

Согласен, что semver сложнее реализовать.
Но он очень нужен. Теоретически либо хранилище образов должно поддерживать функцию "не перезаписывать образы, если они уже есть" (это умеет DTR), либо такой функционал можно реализовать в рамках пайплайна (банально вставить проверку наличия тега и если он есть, то сразу ошибка)

Вы правы, но тогда необходимо каждый раз перед коммитом менять версию вручную (либо автоматизировать) иначе потеряется CD составляющая и не каждый коммит будет попадать на staging.

Если же CD часть не важна, то можно настроить пайплайн на создание образа если комит помечен git тегом с паттерном соответствующим semver. В таком случае не понадобится проверка на перезапись, не нужно менять что-то в коде перед релизом, а так же можно релизить любой коммит из прошлого.
Ну, варианты какие.
Либо нам нужно генерировать образы и промоутить их до продакшн-образа. Либо можно попросту при пуше тега прогонять полный цикл тестов, а не пытаться брать какой-то непонятный образ и менять на нем тег.
В первом случае Ваша методика тегирования образа по timestamp+название ветки выглядит оптимальной. Внутри образа можно через label зашить то, из чего он получен (sha commit и прочие метаданные).
Во втором случае — у нас проблем особо нет, т.к. пуш тега в gitlab-ci генерирует новый пайплайн. Полностью новый пайплайн. Единственное, в чем мы теряем — в скорости релиза. Ну, и немного разваливается концепция прогона образа по пайплайну между средами.

За кадром остались вопросы конкурентности сборок ) Очень неприятно, когда у тебя пайплайн на тег может отработать быстрее, чем основной пайплайн. Или что-то нужно делать с пайплайнами, которые пишут в образ с одним и тем же тегом (например, latest). В принципе, можно их ограничить кол-вом 1 пайплайна за раз… Но тоже такое решение.

Поэтому я полностью согласен, что это реально кроличья нора и чем больше закапываешься, то тем больше нюансов всплывает. А самое главное, что как сервис, это все должно быть удобно разработчикам…
Jenkins будет сразу же настроен на автоматическое создание одноразовых slave для каждой сборки.

Можно поподробнее, как это сделано? кажется что логичнее для такого использовать k8s jobs

Эта функциональность реализована в kubernetes-plugin.


Если я верно понимаю ваш вопрос, то k8s jobs хорошой подойдут для переодически запускаемых задач с фиксированным интервалом. Jenkins позволит создавать slave только когда обнаружено изменение в VCS либо сборка запущена вручную. Основным преймуществом этого подхода является то что slaves существуют только во время сборки, а не все время ожидая начало новой задачи.

Тут все проще, кмк. k8s job не используются, т.к. есть некоторая потребность в управлении жизненным циклом pod-в на стороне Jenkins: управлять переиспользованием и временем жизни поднятых исполнителей и тому подобное.
У меня на практике встречался случай, когда приходилось держать некоторое время под для сборки приложения на JS (которому требовалось выкачивать пару Гб в node_modules), чтобы сократить время повторных сборок. С k8s job такое вряд ли удалось бы провернуть просто потому что, насколько я помню, k8s не позволяет переиспользовать job-ы
Сократить время сборки можно выделив PersistenceVolume для node_modules и каждый раз монтировать его к pod который собирает проект
Да, я знаю, но у нас не было возможности использовать PersistanceVolume — долгая история)
аналогичная история в openshift. Главное — иметь каталог уже готовых образов, из которых будут slave разворачиваться…
Only those users with full accounts are able to leave comments. Log in, please.