А вы что тут пытались только что сделать?

у воркеров монтируется хомяк, сам образ для CI разумеется содержит только инструменты сборки

спс, помог ваш совет, прочитал про pnp и понял что можно использовать node_modules выше по файлухе

И как в итоге yml выглядит?

скрипт сборки в смысле?

У вас ci на чём?

buildkite. Но это неважно, могу логику рассказать

* есть пул воркеров, которые используют один образ для CI, в котором есть собственно агент buildkite, git, node,yarn, gcc, etc..
* у каждого воркера свой персистентный volume который монтируется в $HOME
* логика сборки:
- делается git checkout куда-то в дебри $HOME, скажем $HOME/project - в чистую диру
- запускаются вышеуказанные пассы, которые позволяют использовать ссылку $HOME/project/.../ui/node_modules -> $HOME/node_modules
- запускается yarn install и yarn build которые используют $HOME/node_modules

обычно я раньше использовал всякие плагины для кэширования node_modules по ключу от checksum yarn.lock - но в данном случае это не очень подошло

очевидный минус - у каждого воркера свой "кэш". Но использование шаредного кэша, на котором хранились архивы с node_modules и другими промежуточными артефактами я уже пробовал (NFS/S3) - получалось сильно медленно из-за больших архивов с кучей мелких файлов

В гитлаб примонтированные разделы ещё не завезли, но это решается созданием базовых образов, в которых home содержит зависимости проекта

один из промежуточных архивов был размером в 1ГБ и 5ГБ после распаковки - его скачивание/распаковка/обновление занимало сравнимое с компиляцией время

в образе нельзя хранить кэш сборки, потому что его надо обновлять

ну и в образе совсем нет кода

даже если было бы можно - вы думаете докер регистри будет эффективнее в хранении кэша, чем стоящий рядом NFS или S3?

очень сильно сомневаюсь

В образе не хранится результат сборки, только зависимости

эти зависимости меняются при изменении package.json/yarn.lock

Да, я в курсе ) просто есть ci помимо buildkite

это да :)