Comments 10
Согласен, что semver сложнее реализовать.
Но он очень нужен. Теоретически либо хранилище образов должно поддерживать функцию "не перезаписывать образы, если они уже есть" (это умеет DTR), либо такой функционал можно реализовать в рамках пайплайна (банально вставить проверку наличия тега и если он есть, то сразу ошибка)
Если же CD часть не важна, то можно настроить пайплайн на создание образа если комит помечен git тегом с паттерном соответствующим semver. В таком случае не понадобится проверка на перезапись, не нужно менять что-то в коде перед релизом, а так же можно релизить любой коммит из прошлого.
Либо нам нужно генерировать образы и промоутить их до продакшн-образа. Либо можно попросту при пуше тега прогонять полный цикл тестов, а не пытаться брать какой-то непонятный образ и менять на нем тег.
В первом случае Ваша методика тегирования образа по timestamp+название ветки выглядит оптимальной. Внутри образа можно через label зашить то, из чего он получен (sha commit и прочие метаданные).
Во втором случае — у нас проблем особо нет, т.к. пуш тега в gitlab-ci генерирует новый пайплайн. Полностью новый пайплайн. Единственное, в чем мы теряем — в скорости релиза. Ну, и немного разваливается концепция прогона образа по пайплайну между средами.
За кадром остались вопросы конкурентности сборок ) Очень неприятно, когда у тебя пайплайн на тег может отработать быстрее, чем основной пайплайн. Или что-то нужно делать с пайплайнами, которые пишут в образ с одним и тем же тегом (например, latest). В принципе, можно их ограничить кол-вом 1 пайплайна за раз… Но тоже такое решение.
Поэтому я полностью согласен, что это реально кроличья нора и чем больше закапываешься, то тем больше нюансов всплывает. А самое главное, что как сервис, это все должно быть удобно разработчикам…
Jenkins будет сразу же настроен на автоматическое создание одноразовых slave для каждой сборки.
Можно поподробнее, как это сделано? кажется что логичнее для такого использовать k8s jobs
Эта функциональность реализована в kubernetes-plugin.
Если я верно понимаю ваш вопрос, то k8s jobs хорошой подойдут для переодически запускаемых задач с фиксированным интервалом. Jenkins позволит создавать slave только когда обнаружено изменение в VCS либо сборка запущена вручную. Основным преймуществом этого подхода является то что slaves существуют только во время сборки, а не все время ожидая начало новой задачи.
У меня на практике встречался случай, когда приходилось держать некоторое время под для сборки приложения на JS (которому требовалось выкачивать пару Гб в node_modules), чтобы сократить время повторных сборок. С k8s job такое вряд ли удалось бы провернуть просто потому что, насколько я помню, k8s не позволяет переиспользовать job-ы
@gmandneprСпасибо за пост. Установил jenkins в kubernetes. Пытаюсь включить аутентификацию через google-login автоматически, не руками. Не получается. Я так понимаю скрипты настройки не могут войти в Jenkins, потому что там используется google-login. Я так понимаю что вы тоже с этой проблемой столкнулись. Зделал issue. Может будут идеи.
CI/CD используя Jenkins на Kubernetes