нет

Нахера его собирать 2 часа?

потому что он большой и собирается 2 часа?

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

если вы готовы с этим мириться - то ок

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

Штоэ?

Штааааа?

результат билда зависит от состояния кэша

...This means that every time a build is triggered, either manually or by a new Git commit, a fresh Git clone of the application’s repository occurs. When this happens the mtime of all the cloned files are set to the time of when the clone occurred (including our application’s package.json)...

Кеш дает возможность не делать одинаковые действия если из нее надо делать

Мтайм не важен

В моей практике куча проблема сборки магически решалась при полном билде с нуля

Магии там никогда нет

магии вообще нет - есть необъяснимое и малопонятное поведение

которое решается гарантировано сборко с нуля

В моей практике вся эта магия всегда объяснима и подсказывает проблему

Которую надо решить один раз и дальше экономить время

Решение "хрен его знает что происходит" для своего проекта - моветон

причем здесь "свой проект". речь о тулченах и проблемах, которые испытвают всю

я правда в первую очередь с таким сталкивался в мобильной разработке

особенно в икскоде

и в андроиде с ndk

просто иногда не пересобирается то, что должно пересобраться

Да, in-house: www.concourse.ci

круто выглядит, нужно будет попробовать у себя поставить

я правда в первую очередь с таким сталкивался в мобильной разработке

Да, в мобильной разработке полный бардак

Согласен, извините за наезды

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

Но в вебе сейчас не так. Кеш сборки докера реально решает

Мтайм не важен

а что важно?

ну по логике - откуда докер может знать, что npm install зависит от package.json?

А он и не должен

Ты ему говоришь

каким образом?

а что важно?

Содержимое. Хеш от тара

каким образом?

Когда делаешь докер файл

ну, конкретнее)

Сначала копируешь пакадж, потом делаешь npm i

И докер выполняет инсталл только если поменялся пакадж

ну это же неправильно. Что если я хочу последнии версии пакетов

Правильно. Хочешь последние версии пакетов - меняешь пакадж. Или ты не фиксируешь версии? Рекомендую начать

это частный случай, я говорю про то что докер много на себя берет

Например еще когда?

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

курлом

и хочу что всегда была последняя версия

Это значит - что-то делается не так

ну если докер просто кэширует в такой ситуации - то он не прав

Почему?

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

Есть описанные правила кеширования. Там указано - либо команда либо состав файлы

в общем ясно, докер исходит из того что результат зависит от файлов в последнем ADD

примерно как make

но в make есть phony, в Dockerfile видимо нет такого

Докер каждый раз ориентируется на команду. Если она не менялась - берем кеш. Если менялась - ее и все дальше инвалидируем

https://github.com/docker/docker/issues/1996

Можно явно передать рандом

Сегодня ребята из Cloudflare посоветовали выделить node_modules в отдельный image

приехали

Иногда допустимо

так.. в плане идеи генерации - можно node_module версионировать ( тупо убрать из .gitignore )

ох

это сработает, но явно сделает жизнь сложнее

я про отдельный image

node_modules в гите - норм

Нодмодули в отдельном имадже нужны для ускорения сборки и уменьшении трафика

В гит их, имхо, моветон

ERROR: S client not available

почему? наоборот, просто и надежно

Имхо лучше делать слой пресборки

есть только проблема с бинарниками

их таки все равно нужно пересобирать

В гит их, имхо, моветон

Версионирование Bundle-ов - старая давно работающая техника

их таки все равно нужно пересобирать

Зачем?

ну если dev и prod на одной os и архитектуре - то не нужно

Версионирование Bundle-ов - старая давно работающая техника

Нет смысла в этом когда есть докер

ну если dev и prod на одной os и архитектуре - то не нужно

Ну да, хорошая идея - держать билд сервер таким же как прод

ну npm install делает дев, на дев машине

и в гит кладет бинарники

это плохо - в остальном норм

Ну да, хорошая идея - держать билд сервер таким же как прод

У нас это Kuberenetes-кластер, так что удовлетворяет условию)

для ci?

ну npm install делает дев, на дев машине

Нет. Это делает билдсервер

я говорю про node_modules в гите

И опять плохо - а сасс например? Он ж зависит от архитектуры

я и говорю, это единственная проблема

при билде нужно собирать нативные модули

для ci?

Для проекта :)

И опять плохо - а сасс например? Он ж зависит от архитектуры

SASS вообще зло

Злоо

А чего билд зависимостей не собирать в buildDependencies?

Уж всяко лучше, чем в гит кидать

Это что?)

А чего билд зависимостей не собирать в buildDependencies?

Речь шла о том, что эти зависимости должны были бы попасть в эту категорию, если бы она существовала. npm не знает никаких категорий, кроме depends и devDepends

Это то, что попадает в пакет когда он пакуется перед публикацией в реестре.

Но можно в принципе не публиковать, а собирать отдельный тар.

Получится такой пакет-пакетов, как у всех на кухнях есть)

Речь шла о том, что эти зависимости должны были бы попасть в эту категорию, если бы она существовала. npm не знает никаких категорий, кроме depends и devDepends

Не совсем понял. В npm есть 5 типов зависимостей.

Не совсем понял. В npm есть 5 типов зависимостей.

Ну остальные либо изначально специфические, либо бесполезные в данном случае

Ладно, завтра поэкспериментирую