построить процесс тэгирования образов или где про это прочитать можно?
Это несвязанный с гитлабом и образами вопрос. Нет "правильно", есть удобное для конкретного случая. Гугли git workflows, читай, выбирай
Рабочий вариант - sha + time stamp
Я не понимаю, как с этим работать, так как у меня билд в мастере делается, деплой в дев и тест - тоже в мастере, а деплой в прод и стейдж - только в релиз ветке. И вот в релиз ветку я ж не смогу передать переменную. Если не указывать конкретную версию, то я облажают на редеплое, так как стяну последнюю версию из регистри...(
Частично я косяк свой понял: commit sha (в т.ч. и short commit sha) при билде в мастер и последующем мерже в релиз будут одинаковые, при в стейдже при редеплое ничего не будет плохого, если я укажу тегом commit sha. А с продом как быть? Я придумал только такой костыль: Добавить джобу, когда выкатываю продакшн, чтобы перед деплоем она ставила тэг на существующий образ. Вроде как через curl и access token в гитлабе можно тэг добавить: https://gitlab.com/gitlab-org/gitlab/-/issues/15252 Либо пуллить, добавлять тэг и отправлять обратно в регистри.
Вы можете использовать теги для коммитов Навешивать нужный тег на коммит, в котором образ собрался и тесты пробежали Потом для прода в прод ветке навешивать такой же тег на нужный коммит, образ уже не собирать, а использовать собранный В гитлабе переменная CI_COMMIT_TAG Главное, с коммитами не промахнуться))
Не совсем понял этого, если честно. Я во время билда не знаю на 100%, пойдет ли эта сборка в прод или нет. Могут тесты упасть или на стейдже заказчик забраковать, а в релизе я должен четко и однозначно юзать образ с тегом версии.
Сделай задачу promote to prod
Тогда без доп шагов мой способ не подойдёт, ага
Про promote to prod и теги есть идея Последним шагом пайплайна для дев веток делаем build_prod_image Там собираем образ с тегом по этой схеме, его же деплоим в прод ветке Ну а дев енвы гоняются с докер образами, на которые навешан другой тег, пусть даже commit_sha
Обсуждают сегодня