Table of Contents
- Installation Développement
Installation Développement
Cette page décrit comment démarrer l'environnement de développement local pour les projets Bonsai API et Bonsai Webapp.
Prérequis
| Outil | Version minimale |
|---|---|
| Podman | 5+ |
| podman-compose | 1+ |
Aucun Java ni Node.js à installer sur le poste : tout tourne dans des conteneurs.
Cloner les dépôts
git clone https://git.goutailler-olivier.com/bonsai/bonsai-api.git
git clone https://git.goutailler-olivier.com/bonsai/bonsai-webapp.git
Les deux dépôts doivent être côte à côte dans le même dossier parent (ex. IdeaProjects/). Le docker-compose.dev.yml et le script dev.sh se trouvent dans ce dossier parent.
Option A — Lancer l'API (recommandé)
Depuis Bonsai-api/ :
./dev.sh
- API Spring Boot :
http://localhost:8080 - PostgreSQL :
localhost:5432 - Swagger UI :
http://localhost:8080/swagger-ui.html
Stratégie de cache — API
| Volume | Contenu | Mécanisme |
|---|---|---|
gradle_home |
Dépendances Gradle (~/.gradle) |
Téléchargement uniquement si une nouvelle dépendance apparaît |
gradle_build |
Artefacts de build | Évite les recompilations complètes |
Option B — Lancer le frontend
Depuis Bonsai-webapp/ (l'API doit être démarrée au préalable) :
./dev.sh
- Frontend Angular :
http://localhost:4200
Le proxy Angular redirige /api vers http://host.containers.internal:8080 (l'API sur le poste hôte).
Stratégie de cache — Webapp
| Volume | Contenu | Mécanisme |
|---|---|---|
webapp_node_modules |
node_modules Angular | Initialisé depuis l'image ; l'entrypoint détecte les changements de package.json via SHA-256 et relance npm ci automatiquement |
npm_cache |
Cache téléchargements npm (~/.npm) |
Accélère les npm ci déclenchés par un changement de package.json |
Reconstruction forcée
Si les dépendances ne se mettent pas à jour correctement :
./dev.sh down -v # supprime aussi les volumes de cache
./dev.sh # reconstruit l'image et recrée les volumes
Option C — API seule sans webapp (Gradle local + PostgreSQL Docker)
Depuis le dossier Bonsai-api/, démarrer uniquement la base de données + l'API :
podman-compose -f docker-compose.dev.yml up --build
Flyway applique automatiquement la migration V1__init.sql au premier démarrage.
Variables d'environnement
En développement, les valeurs par défaut sont utilisées automatiquement (définies dans src/main/resources/application.yml). Aucun .env n'est nécessaire.
| Variable | Valeur locale | Description |
|---|---|---|
DATASOURCE_URL |
jdbc:postgresql://localhost:5432/bonsai |
URL JDBC |
DATASOURCE_USERNAME |
bonsai |
Utilisateur PostgreSQL |
DATASOURCE_PASSWORD |
bonsai |
Mot de passe PostgreSQL |
KEYCLOAK_JWKS_URI |
https://auth.goutailler-olivier.com/realms/bonsai/protocol/openid-connect/certs |
Endpoint JWKS |
CORS_ALLOWED_ORIGIN_PROD |
https://bonsai.goutailler-olivier.com |
Origine CORS de prod |
L'origine http://localhost:4200 est toujours autorisée en CORS (front Angular en dev).
Documentation de l'API
Swagger UI est disponible à l'adresse suivante une fois l'API démarrée :
http://localhost:8080/swagger-ui.html
La spécification OpenAPI (JSON) est accessible sur :
http://localhost:8080/v3/api-docs
Lancer les tests
./gradlew test
Le rapport HTML est généré dans build/reports/tests/test/index.html.
Structure du projet
src/main/java/fr/bonsai/api/
├── domain/model/ # Entités métier (sans dépendance Spring)
├── application/
│ ├── port/in/ # Interfaces des use cases
│ ├── port/out/ # Interface du repository
│ └── usecase/ # Logique métier (IssueService)
├── adapter/
│ ├── in/web/ # Controllers REST et DTOs
│ └── out/persistence/ # Entités JPA et adaptateur repository
└── config/ # Configuration Spring (Security, CORS, Beans)
Sécurité
Toutes les routes nécessitent un token JWT Bearer valide émis par Keycloak :
- Realm :
bonsai - Client :
bonsai-webapp - Issuer :
https://auth.goutailler-olivier.com/realms/bonsai
Pour tester sans Keycloak local, utiliser l'instance de production comme fournisseur JWKS (valeur par défaut).
Authorization: Bearer <token>
Endpoints disponibles
| Méthode | Route | Description |
|---|---|---|
GET |
/issues |
Liste toutes les issues |
POST |
/issues |
Crée une issue |
PUT |
/issues/{id} |
Remplace une issue |
DELETE |
/issues/{id} |
Supprime une issue (204) |
CI/CD
Le pipeline Gitea Actions (.gitea/workflows/) construit l'image Docker et la pousse sur le registre interne à chaque push sur main. Le runner ubuntu-latest est fourni par le conteneur act_runner de la stack Gitea.