Kotlin Build Rule Enforcer (kbre)

7 авг. 2024 г. | 3 минуты | Перевод: en (Kotlin Build Rule Enforcer (kbre))

Если посмотреть на типичный проект Котлин, то очень много внимания отнимает Gradle на технические вещи. Вместо одного файла целая пачка в самом корне проекта:

gradle/
buildSrc/
build.gradle.kts
gradle.properties
gradlew
gradlew.bat
settings.gradle.kts

Может ли быть лучше? Да, на других платформах (TypeScript / Python) обычно 1 файл (и может еще 1 файл с точными версиями зависимостей). Да и в том же Maven 1 файл.

Вторая проблема: если у нас микросервисы, то таких проектов множество. И хорошо бы их обновлять, и как-то синхронизировать.

Что же делать? Идеально – новую билд-систему:

1-2 файла настроек
оставить возможность легкого скриптования (почему не Maven)
добавить разрешение зависимостей по SemVer как на других платформах

Но это долго, тяжело и вряд ли под силу одному человеку за несколько дней.

Поэтому более простой путь: на Gradle сверху навесим утилиту, которая будет генерировать файлы для Gradle. Так что движок будет использоваться Gradle, а работать непосредственно будем с kbre.

KBRE (Kotlin Build Rule Enforcer):

генерирует файлы gradle (в том числе и обновляет их)
генерирует новый проект
минимальные технические детали (скорее как start.spring.io, чем как было в Gradle)
самоуверенный: настроено под свои предпочтения, не для всех (иначе не получатся минимальные технические детали)
легко настраиваемый: понятно, что предпочтения в разных организациях / подразделениях разные, так что это легко настраиваемо
важно разделение на общие настройки и настройки проекта
хранит настройки в ~/.kbre – рекомендуется их положить под git и сделать едиными для организации / подразделения
явные версии в сгененированных файлах (тогда IDE легко может подсказывать, что зависимость устарела, но нужно править в kbre.yaml или ~/.kbre)
потенциально можно все файлы Gradle-файлы добавить в gitignore, но пока что рекомендуется их сохранять в git, чтобы kbre работала только при изменении сборки, а не для самой сборки.

Пример файла настроек kbre.yaml:

group: com.example
artifact: demo
name: Demo
description: Demo app
preset: spring
type: root
extensions:
  - webflux
  - mysql
  - redis
dependencies: |
  implementation("as:asd:1.2.3")
extra: |
  # any text

Структура ~/.kbre:

preset1/
  root/
  extensions/
    yaml/
      gradle/
        libs.versions.toml
	  deps.kts
  extension2/
preset2/

Описание каталога настроек (краткое, подробнее в репозитории):

Сначала идут пресеты (например, spring, cli, или ktor) – это как шаблоны в IDE
Типы – root для корневого проекта, другие могут быть, например, для каких-то подпроектов Gradle
Расширяния (extensions). Для каждого пресета свои. Позволяют подключать функционал: например, подключаем jooq со своими файлами в папке bin, зависимостями и кастомным кодом в build.gradle.kts.

Как поставить kbre:

cd ~
git clone https://github.com/stepin/kbre-default-config .krbe

alias kbre='docker run --rm -it -v $PWD:/data -w /data --user "$(id -u)" stepin/kbre'
kbre version

Репозитарий настроек по умолчанию: https://github.com/stepin/kbre-default-config

При создании репозитария для каждого функционала важно выбрать:

является он обязательным или нет (выносить его в расширение или нет)
он будет генерироваться только первый раз или постоянно (основная папка или с суффиксом -new)

Создаем новый проект:

mkdir my-app
cd my-app

cat > kbre.yaml << \EOF
group: name.stepin
artifact: myapp
name: My app
description: Some description
preset: spring
type: root
extensions:
  - graphql
  - postgres
  - flyway
  - jooq
  - dokka
  - jib
  - local-dev
  - systemd-deployment
variables:
  REPO: 'http://localhost:3000/stepin/kotlin-bootstrap-app/src/branch/main/src/main/kotlin'
  SONAR_HOST_URL: 'http://localhost:9000'
  SONAR_PROJECT_KEY: kotlin-bootstrap-app
  SONAR_PROJECT_NAME: kotlin-bootstrap-app
  SONAR_TOKEN: sqp_821b1d3209761625bdd29259674237d429bce626
EOF

kbre new

Обновляем существующий проект:

cd my-app

kbre update

Проект: https://github.com/stepin/kbre