The project uses libraries which make use of code generation with ksp
(Ktorfit, Room,
ComposeDestinations). When building the project the needed files will be generated automatically.
To initially generate all the files without building the whole project you can also run
./gradlew kspDebugKotlin
. This may also be necessary after you updated the git repository
(e.g. pull, switch branch, ...). In case some classes/functions etc. can not be found run this
command to be sure that all the generated files are up to date.
The project uses ktlint and detekt to ensure a consistent code style. On first gradle sync git pre-commit and pre-push hooks are generated. When committing ktlintFormat is run and the formatted files are added back to the commit. When pushing ktlintCheck and detekt is executed. If there is a issue with formatting then the push gets rejected. The issues are listed in the console and also can be found in the build/reports folder. The listed issues must be fixed before you can push to remote.
The hooks can be skipped by using the --no-verify
flag with the git commands. However the CI will
validate the style again and merging will not be allowed if the checks do not pass.
The tasks can also be executed manually using ./gradlew ktlintCheck
(or ./gradlew ktlintFormat
to auto format all files) and ./gradlew detekt
.
The gradle releaseTest
task does all the magic for you. It will create and push a test tag
(e.g. v2.0.0-test-12345
). This will trigger a CI/CD workflow which creates a release for testing.
The signed apk and aab will be uploaded to GitHub-Releases.
From there it can be downloaded and manually installed.
Make sure that the working tree is clean, otherwise the command will fail.
Test releases will use the test deployment of the backend.
./gradlew releaseTest
The gradle release
task does all the magic for you. If no parameters provided it will keep the
version and increases the build number by one.
Make sure that the working tree is clean, otherwise the command will fail.
Builds will use the production deployment of the backend.
./gradlew release
If you only want to update the version and automatically increase the build number use following command:
./gradlew release -Pv=2.0.0
If you want to override both use
./gradlew release -Pv=2.0.0 -Pb=123
- Create a new release branch (can be skipped when already releasing from a non protected branch)
- Run the release gradle task (optionally specify the version and/or build number). For current
version have a look at the tags or the
gradle.properties
file.- Will increase the version specified in
gradle.properties
and commit this change - Create and push a version tag (e.g.
v2.0.0-b10
) - Trigger the publish to internal Testing CI/CD workflow
- Will increase the version specified in
- Go and grab a coffee while waiting till the CI/CD pipeline builds and publishes the app
- Download the new version from Google Play (you have to be part of the internal testers group)
- Test if the app works properly
- If the app should be released to the public then go to the Google Play console and promote the
just released version from
internalTesting
torelease
track- Do not forget to add a Version note!
- Depending on the release type:
- Production release: Merge the branch where the release was made from into main and main back into develop.
- Otherwise: Merge the branch where the release was made into develop.
- Gradle Build tool
- Gradle wrapper Fixed Gradle version in all environments
- Gradle Kotlin DSL Type safe Gradle build configs
- Kotlin Main language
- Coroutines, Suspending Functions & Flow
- KSP Kotlin Symbol Processing
- Ktorfit HttpClient abstraction
- Ktor HttpClient
- Kotlinx Serialization JSON serializer
- Room Database abstraction
- Koin Dependency Injection
- Jetpack Compose
- Compose Destinations Type safe navigation
- Coil Async image loading and caching
- Material 3
- Ktlint Kotlin linter
- ktlint-gradle Ktlint gradle plugin
- Detekt Kotlin static code analyzer
- GGP Gradle Play Publisher Plugin