komga/DEVELOPING.md
Gauthier Roebroeck 20b2b39d36 feat: change database from H2 to SQLite
This is a major change, but done transparently.

At startup, a migration from H2 to SQLite will be triggered:
- if the H2 database is a file (not in memory)
- if the H2 database has not been migrated yet
- if the SQLite database is newly minted

All the data will be transferred from H2 to SQLite before the startup of the application (before the API can serve any requests).
After the migration, an empty file will be stored next to the H2 database file (same name with ".imported" suffix).

The H2 database files will be automatically removed in a later version.

A new configuration key is available to customize the file path of the SQLite database: `komga.database.file`

The database backup feature has been removed. It might be re-added later on using a different logic.

The IDs of entities have been changed from number to string in the API.

closes #218
2020-07-16 07:54:53 +08:00

2.8 KiB

Development guidelines

Thanks a lot for contributing to Komga!

Requirements

You will need:

  • Java JDK version 8 or 11
  • Nodejs version 10+, with npm version 6+

Commit messages

Komga's commit messages follow the Conventional Commits standard. This enables automatic versioning, releases, and release notes generation.

Commit messages are enforced using commit hooks ran on the developer's PC. To install the necessary tooling, you need to run npm install in the root folder of the project. This will install the necessary commit hooks.

Project organization

Komga is composed of 2 projects:

  • komga: a Spring Boot backend server that hosts the APIs, but also serves the static assets of the frontend.
  • komga-webui: a VueJS frontend, built at compile time and served by the backend at runtime.

Backend development

Spring profiles

Komga uses Spring Profiles extensively:

  • dev: add more logging, disable periodic scanning, in-memory database
  • localdb: a dev profile that stores the database in ./localdb.
  • noclaim: will create initial users at startup if none exist and output users and passwords in the standard output
    • if dev is active, will create admin@example.org with password admin, and user@example.org with password user
    • if dev is not active, will create admin@example.org with a random password that will be shown in the logs

Gradle tasks

The backend project uses gradle to run all the necessary tasks. If your IDE does not have gradle integration, you can run the tasks from the root directory using ./gradlew <taskName>.

Here is a list of useful tasks:

  • bootRun: run the application locally, useful for testing your changes.
  • copyWebDist: build the frontend, and copy the bundle to /resources/public. You need to run this manually if you want to test the latest frontend build hosted by Spring.
  • test: run automated tests. Always run this before committing.
  • jooq-codegen-primary: generates the jOOQ DSL.

bootRun needs to be run with a profile or list of profiles, usually:

  • dev,noclaim: when testing with a blank database
  • dev,localdb,noclaim: when testing with an existing database

There are few ways you can run the task with a profile:

  • ./gradlew bootRun --args='--spring.profiles.active=dev'
  • On Linux: SPRING_PROFILES_ACTIVE=dev ./gradlew bootRun
  • On Windows:
SET SPRING_PROFILES_ACTIVE=dev
./gradlew bootRun
  • If you use IntelliJ, some Run Configurations are saved in the repository and available from the Gradle panel

Frontend development

You can run a live development server with npm run serve from /komga-webui. The dev server will override the URL to connect to localhost:8080, so you can also run gradle bootRun to have a backend running, serving the API requests. The frontend will be loaded from localhost:8081.