Про спринг тонко

у меня есть документально заверенный скриншот церковью 2 пришествия бина, как гуга поясняет за спринг и нахваливает его

т.е. получается на каждый коммит он качает заново все завимости

нет

а где кеширование тогда?

Гуга, как ты мог

ты прочитай, что я выше написал

нет

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

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

guga

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

or

я всегда ставлю имя проекта

1 кэш на проект

на все брэнчи и тэги

хм, а если ты поменял build.gradle, как он понимает, что время обновить кеш?

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

хм, а если ты поменял build.gradle, как он понимает, что время обновить кеш?

я не знаю как он это делает, но это работает

орнул

проверено за 2 года работы

я не знаю как он это делает, но это работает

автоимпорт в идее?

может хэш, может еще как-то

автоимпорт в идее?

речь про сиай

ah, sry

проверено за 2 года работы

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

вот как работает в circle - restore_cache: # restore the saved cache after the first run or if pom.xml has changed key: circleci-demo-java-spring-{{ checksum "pom.xml" }} - run: mvn dependency:go-offline # gets the project dependencies - save_cache: # saves the project dependencies paths: - ~/.m2 key: circleci-demo-java-spring-{{ checksum "pom.xml" }} и мне это кажется пиздец костыльным

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

?

не понял сценария

я бы в CI конвеер сейчас настроил сборку без локального кеширования.

я бы в CI конвеер сейчас настроил сборку без локального кеширования.

Долго

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

и отдельной джобой

не понял сценария

есть такой кейс.

типо есть либа

от нее зависят другие проекты

пересобрал либу - можно настроить триггер на пересборку зависимых проектов

Долго

оправдывается если большой проект.

вот как работает в circle - restore_cache: # restore the saved cache after the first run or if pom.xml has changed key: circleci-demo-java-spring-{{ checksum "pom.xml" }} - run: mvn dependency:go-offline # gets the project dependencies - save_cache: # saves the project dependencies paths: - ~/.m2 key: circleci-demo-java-spring-{{ checksum "pom.xml" }} и мне это кажется пиздец костыльным

какая-то херня

гитлаб сразу понимает, что какой-то либы нет в кэше

и качает ее

какая-то херня

То что ты описал в гитхабе, такой же костыль

может по имени сравнивает

То что ты описал в гитхабе, такой же костыль

почему костыль?

как правильно?

ну или на стадию - тестN выдавал только со сборкой без кеша

Очевидно, что каждый раз качать.

Но это долго

спасибо

твое мнение мне не интересно

В Gradle нужно делать clean?

В Gradle нужно делать clean?

Смотря чего ты хочешь.

Смотря чего ты хочешь.

В мавене нужно делать а в Gradle как то кешируется?

В мавене нужно делать а в Gradle как то кешируется?

Что кешируется? Clean не сбрасывает кеши зависимостей, клин сносит папку /target или /build в зависимости от тула

В мавене нужно делать а в Gradle как то кешируется?

/build /.gradle/caches

Что кешируется? Clean не сбрасывает кеши зависимостей, клин сносит папку /target или /build в зависимости от тула

Точно не помню на битбакете писали что есть кеш и клин не обязателен

Наверно про скачиваемые зависимости

Из репозитория

Точно не помню на битбакете писали что есть кеш и клин не обязателен

Ну есть такая штука, как инкрементальная если не делать клин, то в идеальном мире сборщик скомпилит только изменившиеся классы

А ну и Мавен их сохраняет в .m2

Но это кое как работает при локальной сборке

На ci лучше собирать с нуля.

гуга не предлагает решения

но критикует

типикал

Критикуют кто знают ответ

щас бы качать все зависимости

Лул, я же обычный hr, какое ты хочешь решение? Я посмотрел на circle, почитал как предлагает делать gitlab и решение circle кажется немного лучше, хотя и таким же топорным

назови боль

что тебя смущает

гитлаб кстати каждый раз при сборке извлекает кэш

ERROR: S client not available

Первый предлагает перекачивать зависимости только если поменялся файл билда

Гитлаб предлагаем привязятся к чему-то определённому из репозитория

Но что делать когда у тебя bom подход?

И ты вообще не указываешь версии зависимостей?

Первый предлагает перекачивать зависимости только если поменялся файл билда

это все разговор про - мы хорошие парни, мы друг другу верим. Но ведь это не так :)

А кто ставил гатлаб на убунту?

это все разговор про - мы хорошие парни, мы друг другу верим. Но ведь это не так :)

Вот потому я и говорю, что лучше перекачивать зависимости каждый раз

качай

какие проблемы

напоминает уровни изолированности транзакций

не всегда же надо юзать самый жесткий и контроллируемый

Идём к Баруху, покупаем артифактори, идём в грейдл, покупаем дистрибьютед кеш, и разворачиваем это в одном локальной сети с ci

Вот потому я и говорю, что лучше перекачивать зависимости каждый раз

вот и я говорю. кэширование это фича, а не безусловный плюс.

Что лучше брать с апт или омнибус

Пойду продавать людей, а то как-то думать пришлось и решать проблемы которых у меня даже нету.

Что лучше брать с апт или омнибус

Омнибус

Или апт

?

Плюс апт в том, что через апт гет установишь все апдейты с очередным rce

знаете как circle ci кешериует? береть хеш от файла build.gradle и если совпал достает локальный реп и засовывает в контейнер

гитлаб всегда делает экстракт кэша монтируя путь из директивы в .gradle/caches, дальше кэшем рулит сам грэдл. Тоже самое и мэйвена касается.

Плюс апт в том, что через апт гет установишь все апдейты с очередным rce

Хочется поставить и забыть про проблемы с обновлениями

Хочется поставить и забыть про проблемы с обновлениями

Тогда апт

Ибо вместе со всей системой обновляться будет

Но это просто спросил мне совсем не надо ?

Можно делать пул через ssh и билдить на сервере

И все равно, я бы не рекомендовал gl светить во внешний мир

Тогда апт

это тот который apt-get update && apt-get upgrade ? или что то еще есть?

гитлаб всегда делает экстракт кэша монтируя путь из директивы в .gradle/caches, дальше кэшем рулит сам грэдл. Тоже самое и мэйвена касается.

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

это тот который apt-get update && apt-get upgrade ? или что то еще есть?

Этот, да

Этот, да

это же тогда концептуально то же самое. Если рассмотреть под призмой окукливания интернета в локальные сегменты.