ci: pipeline Gitea Actions build & push Docker sur push main
- Dockerfile multi-stage (build eclipse-temurin:25-jdk → runtime) - CI : tests via actions/setup-java puis build & push vers registry Gitea - Trigger Watchtower après push sur main - CLAUDE.md + rules projet (.claude/rules/) - Version build.gradle : 0.0.1-SNAPSHOT → 0.0.1 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,53 @@
|
||||
# Architecture — Clean Architecture (Hexagonale)
|
||||
|
||||
## Structure des couches
|
||||
|
||||
L'application suit une **Clean Architecture** avec le pattern Ports & Adapters :
|
||||
|
||||
```
|
||||
src/main/java/com/olhar/olharapi/
|
||||
domain/ ← Entités métier et exceptions (aucune dépendance framework)
|
||||
model/
|
||||
exception/
|
||||
application/ ← Cas d'usage (logique métier), ports d'entrée et de sortie
|
||||
port/
|
||||
in/ ← Interfaces des cas d'usage (appelées par interfaces/)
|
||||
out/ ← Interfaces de sortie (implémentées par infrastructure/)
|
||||
usecase/ ← Implémentations des cas d'usage
|
||||
infrastructure/ ← Adaptateurs sortants (BDD, sécurité, configuration)
|
||||
persistence/
|
||||
entity/ ← Entités JPA (distinctes des entités domaine)
|
||||
mapper/ ← Conversion domaine ↔ JPA
|
||||
repository/ ← Adaptateurs JPA implémentant les ports out
|
||||
security/
|
||||
config/
|
||||
interfaces/ ← Adaptateurs entrants (REST)
|
||||
rest/
|
||||
controller/
|
||||
dto/
|
||||
request/
|
||||
response/
|
||||
mapper/ ← Conversion domaine ↔ DTO REST
|
||||
exception/ ← Handlers d'exception globaux
|
||||
```
|
||||
|
||||
## Règles par couche
|
||||
|
||||
- **`domain/`** : Java pur — pas de Spring, pas de JPA, pas de Lombok avancé. Entités et exceptions métier uniquement.
|
||||
- **`application/`** : interfaces des ports (`port/in`, `port/out`) + services implémentant les cas d'usage. Pas de dépendance à Spring Web ou JPA.
|
||||
- **`infrastructure/`** : adaptateurs Spring/JPA/sécurité. Implémente les ports `out`. Annoté Spring (`@Service`, `@Repository`, `@Component`).
|
||||
- **`interfaces/`** : contrôleurs REST et DTOs. Invoque les ports `in`. Annoté `@RestController`. Pas de logique métier inline.
|
||||
|
||||
## Interdictions
|
||||
|
||||
- Jamais d'import de `infrastructure/` ou `interfaces/` depuis `domain/` ou `application/`.
|
||||
- Jamais de logique métier dans un contrôleur (`interfaces/rest/controller/`).
|
||||
- Jamais d'entité JPA (`infrastructure/persistence/entity/`) retournée directement par un contrôleur.
|
||||
- Jamais d'appel direct à un repository JPA depuis `application/usecase/` — passer par les ports `out`.
|
||||
- Les mappers (`UserPersistenceMapper`, `UserRestMapper`) restent dans leur couche respective, pas dans `domain/`.
|
||||
|
||||
## Règles de code
|
||||
|
||||
- Utiliser **Lombok** pour les entités, DTOs et mappers (mais pas dans `domain/model/` si les entités sont simples).
|
||||
- Pas de commentaires explicatifs sur ce que fait le code — seulement sur le **pourquoi** si non évident.
|
||||
- Pas d'abstraction prématurée : implémenter ce qui est demandé, pas ce qui pourrait être utile plus tard.
|
||||
@@ -0,0 +1,36 @@
|
||||
# Commits et versioning — Olhar-API
|
||||
|
||||
## Scopes Conventional Commits
|
||||
|
||||
Le format global est défini dans les règles workspace (`commit.md`). Scopes spécifiques à ce projet :
|
||||
|
||||
| Scope | Usage |
|
||||
|-------|-------|
|
||||
| `auth` | Authentification, JWT, sécurité |
|
||||
| `user` | Entité utilisateur, inscription, profil |
|
||||
| `photo` | Gestion des photos (upload, listing, métadonnées) |
|
||||
| `db` | Migrations Flyway, schéma |
|
||||
| `config` | Configuration Spring, OpenAPI, CORS |
|
||||
| `ci` | Workflows Gitea Actions |
|
||||
| `docs` | Documentation technique ou fonctionnelle |
|
||||
|
||||
## Versioning dans build.gradle
|
||||
|
||||
La version est définie dans `build.gradle` :
|
||||
|
||||
```groovy
|
||||
version = '0.1.0'
|
||||
```
|
||||
|
||||
Règles de bump (semver) :
|
||||
- `PATCH` : correction de bug, ajout mineur, refactoring
|
||||
- `MINOR` : nouvelle fonctionnalité complète et fonctionnelle
|
||||
- `MAJOR` : changement cassant d'API ou livraison majeure
|
||||
|
||||
Mettre à jour `version` dans `build.gradle` à chaque commit significatif.
|
||||
|
||||
## Convention de branches
|
||||
|
||||
- `main` : code stable, toujours fonctionnel et buildable
|
||||
- `feat/<nom>` : nouvelles fonctionnalités
|
||||
- Merger dans `main` uniquement quand les tests passent.
|
||||
@@ -0,0 +1,40 @@
|
||||
# Documentation — Olhar-API
|
||||
|
||||
## Wiki du projet
|
||||
|
||||
La documentation de Olhar-API est maintenue dans `../Olhar-API.wiki/` (chemin relatif à la racine du projet).
|
||||
|
||||
Les règles générales de mise à jour du wiki sont définies dans les règles workspace (`wiki.md`).
|
||||
|
||||
## Fichiers du wiki
|
||||
|
||||
| Fichier | Contenu |
|
||||
|---------|---------|
|
||||
| `Specification-Fonctionnelle.md` | Comportement visible : endpoints, règles métier, cas d'usage |
|
||||
| `Specification-Technique.md` | Architecture, entités, flux de données, choix techniques |
|
||||
| `Changelog.md` | Historique des modifications (entrée en tête, plus récent en premier) |
|
||||
|
||||
## Quand mettre à jour
|
||||
|
||||
- **Nouvel endpoint** → mettre à jour les deux specs (fonctionnelle et technique).
|
||||
- **Nouvelle entité ou modification de schéma** → mettre à jour la spec technique.
|
||||
- **Changement de règle métier** → mettre à jour la spec fonctionnelle.
|
||||
- **Ajout de dépendance ou changement d'architecture** → mettre à jour la spec technique.
|
||||
|
||||
## Format des endpoints dans la spec technique
|
||||
|
||||
```markdown
|
||||
### POST /auth/register
|
||||
|
||||
**Corps de la requête :**
|
||||
\`\`\`json
|
||||
{ "email": "...", "password": "..." }
|
||||
\`\`\`
|
||||
|
||||
**Réponse (201) :**
|
||||
\`\`\`json
|
||||
{ "token": "...", "user": { "id": 1, "email": "..." } }
|
||||
\`\`\`
|
||||
|
||||
**Erreurs :** 409 si email déjà utilisé, 400 si validation échoue.
|
||||
```
|
||||
@@ -0,0 +1,19 @@
|
||||
# Issues Gitea — Suivi du projet Olhar-API
|
||||
|
||||
## Dépôt principal
|
||||
|
||||
Issues du projet : **https://git.goutailler-olivier.com/Gato/Olhar-API**
|
||||
|
||||
- Lire les issues ouvertes avant de commencer une tâche.
|
||||
- Les implémenter par ordre de priorité (labels, milestones, ordre de création).
|
||||
- Fermer l'issue correspondante après implémentation et push.
|
||||
|
||||
## Dépôt frontend
|
||||
|
||||
Issues côté frontend : **https://git.goutailler-olivier.com/Gato/Olhar**
|
||||
|
||||
- Créer une issue ici quand un changement d'API impacte Olhar-webapp (voir `webapp-integration.md`).
|
||||
|
||||
## Utilisation du skill Gitea
|
||||
|
||||
Utiliser le skill `gitea-issue` pour lire et créer des issues sans quitter le contexte de travail.
|
||||
@@ -0,0 +1,63 @@
|
||||
# Tests — Olhar-API
|
||||
|
||||
## Couverture minimale : 90%
|
||||
|
||||
La couverture (lignes, branches, méthodes) doit être **≥ 90%** en permanence, vérifiée via JaCoCo.
|
||||
Le seuil global est défini dans les règles workspace (`tests.md`).
|
||||
|
||||
## Types de tests
|
||||
|
||||
| Type | Outil | Suffixe de classe |
|
||||
|------|-------|-------------------|
|
||||
| Unitaire | JUnit 5 | `*Test` |
|
||||
| Intégration | JUnit 5 + Testcontainers + PostgreSQL | `*IT` |
|
||||
|
||||
Les tests d'intégration étendent `AbstractIntegrationTest` qui démarre un conteneur PostgreSQL via Testcontainers.
|
||||
|
||||
## Structure attendue
|
||||
|
||||
Pour chaque classe de production, une classe de test correspondante :
|
||||
- `JwtService` → `JwtServiceTest` (unitaire, pas de Spring context)
|
||||
- `AuthController` → `AuthControllerIT` (intégration, `@SpringBootTest`)
|
||||
- `UserRepositoryAdapter` → test d'intégration avec BDD réelle
|
||||
|
||||
## Exécution via Podman (obligatoire)
|
||||
|
||||
Voir `java-env.md` (règles workspace) pour les contraintes. Commande standard :
|
||||
|
||||
```bash
|
||||
podman run --rm -v $(pwd):/workspace:Z -w /workspace eclipse-temurin:25-jdk ./gradlew test --no-daemon
|
||||
```
|
||||
|
||||
Testcontainers nécessite le socket Docker/Podman :
|
||||
|
||||
```bash
|
||||
podman run --rm \
|
||||
-v $(pwd):/workspace:Z \
|
||||
-v /run/user/$(id -u)/podman/podman.sock:/var/run/docker.sock \
|
||||
-w /workspace \
|
||||
eclipse-temurin:25-jdk \
|
||||
./gradlew test --no-daemon
|
||||
```
|
||||
|
||||
## JaCoCo dans build.gradle
|
||||
|
||||
```groovy
|
||||
test {
|
||||
useJUnitPlatform()
|
||||
finalizedBy jacocoTestReport
|
||||
}
|
||||
|
||||
jacocoTestReport {
|
||||
reports { xml.required = true }
|
||||
dependsOn test
|
||||
}
|
||||
|
||||
jacocoTestCoverageVerification {
|
||||
violationRules {
|
||||
rule {
|
||||
limit { minimum = 0.90 }
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,33 @@
|
||||
# Intégration avec Olhar-webapp (frontend)
|
||||
|
||||
## Principe
|
||||
|
||||
Olhar-API est le backend consommé par **Olhar-webapp** (Angular). Tout changement d'API susceptible d'impacter le frontend doit être signalé.
|
||||
|
||||
## Quand créer une issue sur Olhar-webapp
|
||||
|
||||
Créer une issue sur **https://git.goutailler-olivier.com/Gato/Olhar** lorsque :
|
||||
- Un endpoint change de signature (URL, méthode, corps, réponse)
|
||||
- Un nouveau champ est ajouté à une réponse existante (à exploiter côté frontend)
|
||||
- Un endpoint est supprimé ou déprécié
|
||||
- Un comportement d'erreur change (code HTTP, format du message)
|
||||
|
||||
## Contenu de l'issue
|
||||
|
||||
L'issue doit décrire :
|
||||
- L'endpoint concerné (méthode + URL)
|
||||
- Ce qui a changé dans l'API
|
||||
- L'action attendue côté frontend (adapter l'appel, afficher un nouveau champ, etc.)
|
||||
- Si un feature flag côté frontend couvrait l'absence de cet endpoint, préciser qu'il peut être **retiré** maintenant que l'API est disponible (nettoyage du code mock et du flag correspondant)
|
||||
|
||||
## CORS et sécurité
|
||||
|
||||
- Les origines autorisées sont configurées dans `SecurityConfig`.
|
||||
- En développement : `http://localhost:4200` (Angular dev server).
|
||||
- Ne pas ouvrir `*` en production.
|
||||
|
||||
## Contrat d'API
|
||||
|
||||
- Les DTOs de réponse (`interfaces/rest/dto/response/`) constituent le contrat public.
|
||||
- Ne jamais modifier un champ existant d'un DTO sans créer une issue sur Olhar-webapp.
|
||||
- Ajouter des champs est non-cassant ; en supprimer ou en renommer est cassant.
|
||||
Reference in New Issue
Block a user