Комментарии 13
Непонятно про влияние истории гитв на тег. Как он влияет и, главное, зачем?
Цель: изоляция кеша стадий и итоговых образов собранных для разных веток в git. Кеш, собранный для какой-либо ветки от master не будет доступен в master до тех пор, пока эта ветка не будет смержена в master.
Итоговый образ точно также как и кеш стадий будет изолирован за счет создания разных тегов. Вот в этом и заключается влияние истории гита на тег.
Другими словами: вот есть у нас 2 образа одинаковых по контенту, но собранных для разных гит-веток. Верф изолирует эти 2 образа: создаст для каждого свой идентификатор.
При этом в рамках одной ветки образы с общим контентом будут иметь одинаковый идентификатор.
А зачем такая изоляция? Вот сделал я ветку от мастера, что-то в ней делал, подмержил мастер в итоге, сделал билд, получио образ, прогнал его по тестам. Вмерживаю в мастер, делаю билд, но кэш недоступен, всё опять с нуля.
Не так. При мерже собранный кеш становится доступен для всех остальных точно также как и изменения которые были сделаны в ветке становятся доступны всем только после merge. Если мерж был не fast-forward, то возможно произойдет пересборка связанная со слиянием изменений мастера и ветки, но опять же уже собранный кеш будет учавствовать в сборке.
Если для ветки сделать rebase, то кеш, собранный для старого коммита потеряется и более не будет использоваться, также как теряется родительская связь между коммитами при rebase — произойдет пересборка. При дальнейшем merge кеш не теряется.
Такая изоляция — это отчасти переложение логики гита на собираемые образы.
А как по этому тегу потом понять, какая версия кода выполняется (какой коммит конкретно был собран)?
werf deploy добавляет аннотации:
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
ci.werf.io/commit: bedee28e358378b2e20c406628f751499f15d2e3
gitlab.ci.werf.io/job-url: https://gitlab.com/group/project/-/jobs/54301
gitlab.ci.werf.io/pipeline-url: https://gitlab.com/group/project/pipelines/25574
project.werf.io/env: env
project.werf.io/git: https://gitlab.com/group/project
project.werf.io/name: app
service.werf.io/owner-release: app-env
werf.io/version: v1.1.8.4
spec:
template:
spec:
containers:
- name: pod
image: registry.gitlab.com/group/project/image:781a2fa1c6d299fe1f6d5cfa44dfcf0c7e2c6de3eec4d10fbe314523Как вариант — запоминать версию кода на этапе сборки образа. Но опять же commit-id — это неидеальный идентификатор кода, потому что его изменение не означает что код в образе изменился. При этом мог быть сделан какой-то нерелевантный коммит и сборщик не стал лишний раз пересобирать образ без надобности — в этом случае образ остался связан со старым коммитом.
Другой вариант — не встраивать информацию о коммите в образы вообще. Зачем добавлять в образ изменчивую инфу, тем более, что commit-id не отражает его содержимое. А добавлять инфу о коммите куда-то в рантайм — Kubernetes — в процессе выката приложения. При выкате werf, например, через values может передать commit-id в шаблоны. Дальше его можно положить в какой-нибудь ConfigMap, приложение же может доставать commit-id в рантайме — читать его из ConfigMap. Тут получается и овцы сыты, и волки целы: лишних пересборок нету, приложение может получить инфу о гите.
Парни, круто! Тоже сражался с этой проблемой и пришёл к выводу использовать дайджесты образов в виде тэгов. НО, как потом быстро соотнести такой тэг с ревизией vcs?
Спасибо! Ответил тут: https://habr.com/ru/company/flant/blog/495112/#comment_21457234
Content-based tagging в сборщике werf: зачем и как это работает?