Created by Slavomír Kocka, last modified on May 13, 2022

This page contains information about gradle specific configuration.

Gradle is essential tool used for development of microservices on the project. Development process is “gradle centric” meaning, that the gradle build process outcome is the mandatory source of truth, whether commits could be merged to “main” branch and considered correct. This specifically means, that it does not matter, whether code or test do work in idea or whenever, but relevant are only outcomes of build processes within CI (Github Actions).

Usage

Gradle is the key tool for development lifecycle. We do not rely on unified IDEs the main rules is, that gradle build has to always work. This means, that before we even want to request PR each developer has to be sure that his work is compilable and unit tests are passing. Or specifically, that command ./gradlew clean build -x integrationTest does run successfully. In general, we can say, that gradle is our source of truth. Doesn’t matter what your IDE says. Only thing, which matters is the build result. Moreover, this build has to run successfully without local setup (apart from JDK and Docker mentioned above). Most common command used would be:

  • ./gradlew clean build -x integrationTest verifying, that build and local tests are running

  • ./gradlew clean build, runs also integration test. This would be highly module specific, as it might be difficult or even impossible to setup environment, which would run locally.

  • ./gradlew clean build -x test -x integrationTest compilation only. Not really useful.

  • ./gradlew clean test runs local tests.

  • ./gradlew clean integrationTest runs integration tests.

  • Be careful as ./gradlew clean itest is only abbreviation for “itestClasses” - Assembles itest classes. This command actually does not execute integration test.

Structure

We use “kotlin” flavour of gradle, so files in use are:

  • build.gradle.kts - main build file containing plugins, dependency management and other configuration relevant for plugins.

  • settings.gradle.kts - file for defining for example project name & plugin versioning management. In case of multi-project structure (which isn’t our case, as we want to keep microservices loosely coupled as much as possible - for now at least) this is used for grouping common behaviour across projects.

  • gradle.properties - contains constants specific for project.