Здравствуйте, Pauel, Вы писали:

P>>>Каким образом ты обеспечил эту повторяемость?

vsb>>гарантии того, что завтра скачается то же, что сегодня — нет

P>Итого — повторяемости нет. Просто она тебе не нужна.

Ну да, я про это и написал.

P>Скажем, что делать, если зависимости были удалены по каким либо причинам из публичных репозиториев?

Искать эти зависимости где-нибудь или искать другие. Но это фантастическая ситуация, тратить кучу времени и сил на решение проблемы, которая никогда не возникнет — не очень-то разумно. По крайней мере для типового проекта.

>Во время очередного билда выясним, что в проекте надо править зависимости, которые дают баги-несовместимости-итд.
P>Докер дает стабильный результат — никто задним числом не подменит тот самый байтик.

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

Повторяемость может быть важна для некоторых проектов. К примеру для публичных проектов, связанных с безопасностью. Если я скачиваю бинарник того же signal-а, я хочу быть уверенным, что этот бинарник соответствует опубликованным исходникам. И для этого signal поддерживает повторяемость билдов. И даже если я сам это не проверяю, я примерно представляю, что среди тысяч программистов, пользующихся им, хотя бы пара гиков найдётся, которые это проверят за меня и поднимут хай-вай, если что не так.

А для закрытых проектов, ну максимум — какой-нибудь кеш для зависимостей поставить. Удалить-то вряд ли удалят, а вот очередной роскомпозор забанит npm и будет гемор, решаемый, но гемор. К повторяемости это отношения не имеет, но соглашусь, что в оффлайне собирать проект может быть полезно. Я лично это делал в своё время, когда был заказчик, у которого интернета не было и надо было на его территории что-то исправлять/дорабатывать.

Здравствуйте, Pauel, Вы писали:

P>>>Каким образом ты обеспечил эту повторяемость?

vsb>>гарантии того, что завтра скачается то же, что сегодня — нет

P>Итого — повторяемости нет. Просто она тебе не нужна.

Ну да, я про это и написал.

P>Скажем, что делать, если зависимости были удалены по каким либо причинам из публичных репозиториев?

Искать эти зависимости где-нибудь или искать другие. Но это фантастическая ситуация, тратить кучу времени и сил на решение проблемы, которая никогда не возникнет — не очень-то разумно. По крайней мере для типового проекта.

>Во время очередного билда выясним, что в проекте надо править зависимости, которые дают баги-несовместимости-итд.
P>Докер дает стабильный результат — никто задним числом не подменит тот самый байтик.

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

Повторяемость может быть важна для некоторых проектов. К примеру для публичных проектов, связанных с безопасностью. Если я скачиваю бинарник того же signal-а, я хочу быть уверенным, что этот бинарник соответствует опубликованным исходникам. И для этого signal поддерживает повторяемость билдов. И даже если я сам это не проверяю, я примерно представляю, что среди тысяч программистов, пользующихся им, хотя бы пара гиков найдётся, которые это проверят за меня и поднимут хай-вай, если что не так.

А для закрытых проектов, ну максимум — какой-нибудь кеш для зависимостей поставить. Удалить-то вряд ли удалят, а вот очередной роскомпозор забанит npm и будет гемор, решаемый, но гемор. К повторяемости это отношения не имеет, но соглашусь, что в оффлайне собирать проект может быть полезно. Я лично это делал в своё время, когда был заказчик, у которого интернета не было и надо было на его территории что-то исправлять/дорабатывать. Хотя всё равно без существенных причин наверное это лишний труд, по крайней мере для небольших проектов.