У нас есть несколько полноценных проектов A, B, C, D. Это микросервисы, которые начнут делиться сгенерированными протобуфами файлами java. мы думаем о структуре, подобной этой
A
build.gradle (this is a full on gradle build)
B
build.gradle (this is B's full on gradle)
common
build.gradle (build the protobuf that is used by A and B)
Теперь вопрос состоит в том, как мы можем быть уверены, что когда разработчик строит A, он также строит общий в случае, если он изменился при его git тяге. То же самое относится и к B. Файл settings.gradle, похоже, не имеет ../../: проекта или чего-то в этом роде.
Я помню, что Gradle также предложил способ создания нескольких проектов Gradle.
В идеале, когда кто-то меняет общее, несколько сборок jenkins запускаются так же, как и проверка того, что смена ядра Код не сломал ни одну из служб, которые его используют. Я не совсем уверен, как
1. document the things that depend on common
2. use the document to kick off builds of all things depending on common
Тогда, если это будет расти, и у вас есть D зависит от C зависит от общего, каждая сборка должна быть запущена, питая бинарный апстрим от общего к C, а затем банку C и банку обыкновенного для D. Я знаю, что для этого в твиттере используются «штаны». Google использует Базель. Возможно я смотрю на это вместо gradle? или мы можем смешать их?