В первой части было показано общее поведение configuration cache на простых примерах. Теперь перейдем в плоскость практики: рассмотрим с какими проблемами сталкиваются разработчики плагинов и как их можно решать.

Configuration cache должен был стать обязательным в Gradle 9, но требования, в итоге, смягчили. В любом случае, рано или поздно он станет обязательным и авторам плагинов придется его поддерживать.

Я не могу сказать что документация по кэшу плохая, но в ней очень мало практики: каждому разработчику приходится тратить время на эксперементы. Так вот, под катом те самые недостающие эксперименты - как работает gradle configuration cache на примерах.

Есть счастливые люди, которые могут себе позволить просто перезаписывать YAML конфиги в продакшене. Мне же повезло меньше - инсталляции у меня специфичные и конфиги часто настраиваются "под себя". К каждому релизу приходилось готовить отдельную доку для ручного апдейта конфигурации.

Естественно, что руки сами тянутся автоматизировать такое безобразие, но гугл быстро дал понять что не я один мечтаю о хорошем, только вот заветного оазиса пока никто не нашел. Нет, смержить два YAML файлика задача не трудная, но только если готов пожертвовать комментами (что для многих, как и для меня, недопустимо).

Как вы уже могли догадаться, тулзу я в итоге написал свою (java). Но рассказать я хочу не о том что она умеет, а о том что было после "да что я сам не сделаю что ли...".

Кода не будет, просто описание того с чем пришлось иметь дело и что в итоге пришлось сделать (что гораздо интереснее скучных циклов). Заранее извиняюсь за обилие англицизмов.