gitea ci

deploy/README.md

@@ -1,15 +1,18 @@
 # Déploiement
 
-Le pipeline [`.gitlab-ci.yml`](../.gitlab-ci.yml) se déclenche sur **chaque
-push** :
+Le pipeline [`.gitea/workflows/ci-cd.yml`](../.gitea/workflows/ci-cd.yml) (Gitea
+Actions) se déclenche sur **chaque push** :
 
 1. tests (backend : `ruff` + `pytest` + `alembic check` ; frontend :
    `typecheck` + `lint` + `build` + `smoke`) ;
 2. sur `main` seulement : build des images `backend` et `frontend`, poussées
-   sur le registre de conteneurs du projet GitLab ;
+   sur le registre de conteneurs intégré à Gitea ;
 3. copie de `deploy/docker-compose.prod.yml` sur le VPS par SSH ;
 4. `docker compose pull`, migration Alembic, `up -d`.
 
+Nécessite un runner Gitea Actions (`act_runner`, exécuteur Docker) activé sur
+l'instance et attaché au dépôt.
+
 Le VPS n'expose rien directement : un **Caddy déjà installé sur le
 serveur** (service système, hors de ce dépôt) reçoit le trafic public sur
 443 et reverse-proxy vers les deux conteneurs, qui n'écoutent que sur
@@ -39,27 +42,34 @@ serveur** (service système, hors de ce dépôt) reçoit le trafic public sur
   Caddy) : suffisant contre la force brute sur un compte connu, pas contre
   une attaque distribuée sur de nombreux emails différents.
 
-## Étape 0 — pousser le dépôt sur GitLab
+## Étape 0 — pousser le dépôt sur Gitea
 
 ```bash
-# Créer d'abord un projet vide sur GitLab (sans README ni .gitignore), puis :
-git remote add origin git@gitlab.com:<namespace>/<projet>.git
+# Créer d'abord un dépôt vide sur Gitea (sans README ni .gitignore), puis :
+git remote add origin git@gitea.mon-domaine.fr:<namespace>/<projet>.git
 git push -u origin main
 ```
 
-## Variables CI/CD à définir (Paramètres → CI/CD → Variables)
+## Secrets et variables à définir (Paramètres du dépôt → Actions)
 
-| Variable          | Description                                                      |
+Secrets (Paramètres → Actions → Secrets) :
+
+| Secret            | Description                                                      |
 |-------------------|-------------------------------------------------------------------|
-| `SSH_HOST`        | Hôte du VPS                                                        |
-| `SSH_USER`        | Utilisateur SSH                                                    |
-| `SSH_KEY`         | Clé privée SSH (format OpenSSH) — **masquée**, sur `main` seulement|
-| `DEPLOY_PATH`     | Dossier du projet sur le VPS (ex. `/opt/benevoles`)               |
-| `VITE_EDITION_ID` | UUID de l'édition de production — **à ajouter après** l'étape 3   |
+| `REGISTRY_TOKEN`  | Jeton d'accès (scope `write:package`) pour pousser sur le registre de conteneurs de l'instance Gitea |
+| `SSH_KEY`         | Clé privée SSH (format OpenSSH)                                   |
 
-`CI_REGISTRY`, `CI_REGISTRY_USER`, `CI_REGISTRY_PASSWORD` et
-`CI_REGISTRY_IMAGE` sont fournies automatiquement par GitLab, rien à
-configurer.
+Variables (Paramètres → Actions → Variables) :
+
+| Variable             | Description                                                      |
+|-----------------------|-------------------------------------------------------------------|
+| `REGISTRY_HOST`       | Hôte du registre (ex. `gitea.mon-domaine.fr`)                    |
+| `REGISTRY_NAMESPACE`  | Espace du registre (ex. `<organisation>/<depot>`)                |
+| `REGISTRY_USER`       | Utilisateur associé à `REGISTRY_TOKEN`                            |
+| `SSH_HOST`            | Hôte du VPS                                                        |
+| `SSH_USER`            | Utilisateur SSH                                                    |
+| `DEPLOY_PATH`         | Dossier du projet sur le VPS (ex. `/opt/benevoles`)               |
+| `VITE_EDITION_ID`     | UUID de l'édition de production — **à ajouter après** l'étape 3   |
 
 La clé publique correspondant à `SSH_KEY` doit être dans le
 `~/.ssh/authorized_keys` de `SSH_USER` sur le VPS.
@@ -101,10 +111,10 @@ quel — il n'y a rien d'autre à y copier.
 Le frontend a besoin de l'UUID d'une édition pour être construit (voir plus
 bas) : le tout premier déploiement se fait donc en deux temps.
 
-1. Sur GitLab, lancer le pipeline sur `main` normalement (Push → CI/CD →
-   Pipelines, ou un simple commit). Le job `build-frontend` échouera ou
-   produira une image sans édition tant que `VITE_EDITION_ID` n'existe pas :
-   c'est attendu, on l'ignore pour l'instant.
+1. Sur Gitea, lancer le pipeline sur `main` normalement (Push → Actions, ou
+   un simple commit). Le job `build-frontend` échouera ou produira une image
+   sans édition tant que `VITE_EDITION_ID` n'existe pas : c'est attendu, on
+   l'ignore pour l'instant.
 2. Une fois `build-backend` et `deploy` passés, `db` et `backend` tournent
    sur le VPS.
 
@@ -129,10 +139,11 @@ docker compose -f docker-compose.prod.yml exec -T db \
 
 ## Étape 4 — brancher le frontend sur cette édition
 
-Dans GitLab, ajouter la variable CI/CD `VITE_EDITION_ID` avec cet UUID, puis
-relancer le pipeline sur `main` (bouton *Retry* sur le dernier pipeline, ou un
-nouveau commit). Cette fois `build-frontend` construit une image qui pointe
-sur la bonne édition, et `deploy` démarre le service `frontend`.
+Dans Gitea, ajouter la variable `VITE_EDITION_ID` (Paramètres → Actions →
+Variables) avec cet UUID, puis relancer le pipeline sur `main` (bouton
+*Re-run* sur le dernier run, ou un nouveau commit). Cette fois
+`build-frontend` construit une image qui pointe sur la bonne édition, et
+`deploy` démarre le service `frontend`.
 
 `VITE_EDITION_ID` ne change plus ensuite : elle ne se touche à nouveau que
 pour une nouvelle édition (festival de l'année suivante) qu'on voudrait