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

62 lines
2.8 KiB
Markdown

# 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](https://www.conventionalcommits.org/) 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`.