Добрый день. Подскажите, а как правильно подкладывать в определенную стадию

кэш с предыдущих сборок? То бишь при сборе приложения образуются сборочные файлы, их можно сохранить и подложить в следующую сборку, после которой будут уже новые итд.
Вроде с помощью верф стадий можно сделать такое, но не могу допереть как

я подобное просто в слои кеширую

? import: - image: здесь_название_образа_собранного_ранее add: ... to: ... before: ... либо каждый новый образ строить на основе предыдущего: fromImage: ...

А, точно. Забыл, что можно сослаться на предыдущие образы.

А не подскажите, как сослаться на сбилженный ранее образ? название образа: backend В каждой сборке название не меняется. Есть какие-то werf.values, которые позволяют сослаться на backend, но из предыдущей сборки?

Я почитал, для этих целей есть build_dir. Но ее не реккомендуется использовать, вот и думаю это сделать на уровне артефактов

Протегиройте его используя short sha commit, а потом просто используйте env которая содержит это значение в следующей джобе. Я по умолчанию все образы тегирую %image%-{{ env "CI_COMMIT_SHORT_SHA" }}

Не совсем понял. Нужно ведь не захардкоженное значение, а ровно предыдущий билд. То бишь мне надо в wer.yaml, как-то при каждой сборке получать ссылку на ровно предыдущую сборку.

Ну возьмите переменную номер билда минусуйте единицу и вот вам предыдущий билд. У вас это в одном пайплайне? В разных джобах?

И какая цель конечная? Выдрать данные из образа для следующей джобы? Тогда только mount

Да, сборочный кеш между сборками подкладывать к каждой сборке, и после нее обновлять. Да, build_dir прям в точности решает этот вопрос, но он же не реккомендуется докой, вот и думал, как-то артефактами сделать

в слое докера)))

Ага и разориться на хранении папки node_modules )) для каждой сборки, сам же недавно писал и говорил что много образ весит.

werf с докером послойно не кеширует же. Да и не особо поможет это. Спрашивал уже как-то. Потому переписал на stapel. Но вопрос все равно остался, как правильно подложить кше сборок от предыдущих сборок, чтобы ускорить текущую. КРоме build_dir получается никак?

и там нет нодемодулес, ну там где у меня образ много весит

зато быть уверенным что твой кеш не создаёт нигде конфликтов

в моём случае отлично помогает, поясните как это не помогает вам, не понимаю

ну и опять же, большое занятое место будет только в случае если у тебя одновременно много разных вариаций по модулям. В реале врядли такое где-то случается, чаще всего билд изменили и продолжительное время на нём живут, имея может ещё несколько тестовых вариантов которые обкатываются. А в таком случае проблем с местом не будет. И не будет проблем с конфликтами.

Это внутри werf.yaml. Мне же в stapel надо сослаться на образ, из которого делать импорт. Вот как в werf.yaml задать imageFrom: backend - 1 я не знаю )

Abix

к чему это?

Я не совсем понимаю что значит сбилженный ранее. Если образа(его слоев), указанного в import нет в репе - то верф увидит отсутствие и запустит сборку образа указанного в import. И выстроит последовательность запуска чтобы в импорт подложить собранный образ

В плане, образ из прошлого werf converge

я так понимаю в рамках стапеля?

Ну сейчас на стапель перешел да, он более гибкий. Но и с докером проблема не особо решилась бы. Вариант, 1 либо использовать монтирование ( build_dir). Но его прям нереккомендует сама дока верфа, и я вот хз. 2 либо на уровень выше пытаться это решить - в gitlab-ci.yml. То бишь оперировать сборками самого гитлаба. Но нужно будет тогда как-то связывать прокидывать в джобах номера сборок. Вероятно, так можно решить, но усложняет слишком всё.

почему с докером не решилась бы?

Так суть останется таже. Нам нужно сослаться на предыдущий билд. Со стапелем просто это внутри werf.yml всё, а с докером в dockerfile ушло бы, и я даже хз, как это бы решилось внутри dockerfile

не нужно

разберитесь как работают слои в докер

посмотрите на мой скрин, я ни на что не ссылаюсь и при этом слой используется из кеша

Вы не о том. Пакеты и у меня кешируеются. До этого докером, сейчас стапелем. Вообще не важно. Слой уже поменялся. Он будет пересобираться, в него внесли изменения. Вопрос в том, чтобы ПЕРЕД его пересборкой, подложить к нему результат от предыдущей его сборки, чтобы ускорить нынешнюю сборку

или я вас не понимаю или вы всё ещё не понимаете что такое слои в докере