Коллеги, у меня тут возникла одна очень интересная задачка. Есть

один бандл, который содержит в себе 2 типа образов - бэкенд и фронтенд.
Выкатываются последовательно, сперва бэк и потом фронт.
Есть хук, который построен на базе бэкендового образа, чтобы делать миграцию базы данных перед всеми деплоями.
Можно ли как-то сделать так, чтобы хук с миграцией выполнялся только тогда, когда изменился образ бэкенда?
Просто при частых изменениях на фронте, часто приходится ждать его выполнения, хотя по факту он ничего не делает из-за отсутствия изменений.

Добрый день, у вас задача часто выкатывать фронт?

Ага. По несколько раз в день. В песочницу.

Будто бы проще сделать выкат раздельным на уровне CI.

Так а как выкат зависит? Хуку всё равно. Бандлом выкатывается.

А хук у вас какого плана?

обычный helm hook в виде джобы.

А, я понял. Подумал про webhook.

неа... просто джоба. я думал сделать её не как хук, а как первоочерёдный деплой. но что-то мне кажется это какой-то лютый костыль, который не факт что сработает.

@ilya_lesikov глянь пожалуйста, как время будет.

Могу предложить такой велосипед: обернуть Job в if-условие, в условии должна проверяться версия образа бэкенда в текущем деплойменте, которую теоретически можно взять с помощью lookup-функции , с версией нового релиза

Интересно, может средствами CI детектить изменения до сборки образа? И в зависимости от этого выкатывать только то что нужно

Можно попробовать такой вариант: # .helm/templates/migrate.yaml kind: Job metadata: # "v1" in the name must be changed everytime Job spec is changed name: migrate-{{ include (print $.Template.BasePath "/backend.yaml") . | sha256sum | trunc 10 }}-v1 annotations: helm.sh/hook: ... helm.sh/hook-delete-policy: "" # .helm/templates/backend.yaml kind: Deployment metadata: name: backend # .helm/templates/frontend.yaml kind: Deployment metadata: name: frontend Так каждый раз при изменении backend.yaml будет менять имя у Job, вызывая её перекат. Если же манифест джобы (включая её имя) не изменился, её выкат будет пропущен — так умеет werf 2.0. Единственное неудобство это то, что при изменении spec самой джобы, надо будет v1 в её имени поменять на что-то ещё, иначе получите ошибку "не можем обновить Job, т. к. она иммутабельна". Мы планировали добавить что-то вроде "werf.io/deploy-policy: recreateOnImmutableError", но пока не добрались.