gitea ci

CLAUDE.md

@@ -398,11 +398,11 @@ fonctions d'IA. *(L'envoi d'emails par SMTP est en place — voir § 2.)*
 ├── README.md
 ├── docker-compose.yml              # dev : db + backend (hot reload)
 ├── .env.example
-├── .gitlab-ci.yml                  # CI/CD : tests → build (registre GitLab) → SSH sur le VPS
+├── .gitea/workflows/ci-cd.yml      # CI/CD : tests → build (registre Gitea) → SSH sur le VPS
 ├── deploy/
 │   ├── docker-compose.prod.yml     # db + backend + frontend, ports en 127.0.0.1
 │   ├── Caddyfile.benevoles         # bloc à ajouter au Caddy du VPS (reverse proxy)
-│   └── README.md                   # variables CI/CD requises, mise en service du VPS
+│   └── README.md                   # secrets/variables CI/CD requis, mise en service du VPS
 ├── docker/postgres-init/           # création de la base de test au 1er boot
 ├── backend/
 │   ├── pyproject.toml              # géré par uv
@@ -481,19 +481,22 @@ Aucune dépendance locale requise hors Docker.
 
 ## 9. Déploiement
 
-- Dépôt GitLab. VPS avec Docker + un Caddy déjà installé en service système
-  (hors de ce dépôt), qui reçoit tout le trafic public en HTTPS et fait
-  reverse proxy vers les conteneurs.
-- `.gitlab-ci.yml` : à chaque push, tests (backend + frontend) ; sur `main`
-  seulement, build des images `backend` et `frontend` (registre de conteneurs
-  du projet GitLab) puis SSH sur le VPS → copie de
+- Dépôt Gitea (instance auto-hébergée). VPS avec Docker + un Caddy déjà
+  installé en service système (hors de ce dépôt), qui reçoit tout le trafic
+  public en HTTPS et fait reverse proxy vers les conteneurs. Nécessite un
+  runner Gitea Actions (`act_runner`, exécuteur Docker) attaché au dépôt.
+- `.gitea/workflows/ci-cd.yml` : à chaque push, tests (backend + frontend) ;
+  sur `main` seulement, build des images `backend` et `frontend` (registre de
+  conteneurs intégré à Gitea) puis SSH sur le VPS → copie de
   `deploy/docker-compose.prod.yml` → `pull` → migration Alembic → `up -d`.
 - Le frontend est un **build statique** (`frontend/Dockerfile.prod`, servi par
   nginx) : `VITE_API_MODE`/`VITE_EDITION_ID` sont figées au moment du build,
   pas à l'exécution — l'édition de production doit donc exister avant la
   première construction de cette image (voir `deploy/README.md`).
-- Variables CI/CD requises (voir `deploy/README.md`) : `SSH_HOST`, `SSH_USER`,
-  `SSH_KEY`, `DEPLOY_PATH`, `VITE_EDITION_ID`.
+- Secrets/variables Actions requis (voir `deploy/README.md`) : secrets
+  `REGISTRY_TOKEN`, `SSH_KEY` ; variables `REGISTRY_HOST`,
+  `REGISTRY_NAMESPACE`, `REGISTRY_USER`, `SSH_HOST`, `SSH_USER`,
+  `DEPLOY_PATH`, `VITE_EDITION_ID`.
 - Le VPS porte un fichier `.env` (non versionné) avec `POSTGRES_USER`,
   `POSTGRES_PASSWORD`, `POSTGRES_DB`, `JWT_SECRET`, `PUBLIC_BASE_URL` et les
   variables `EMAIL_ENABLED` / `SMTP_*` (voir `deploy/README.md`).