gitea ci
ci-cd / backend-test (push) Failing after 7m57s
ci-cd / build-backend (push) Skipped
ci-cd / frontend-test (push) Failing after 32s
ci-cd / build-frontend (push) Skipped
ci-cd / deploy (push) Skipped

This commit is contained in:
AdamThomas
2026-09-16 21:09:28 +02:00
parent 0ede409841
commit 010cac8adc
8 changed files with 237 additions and 170 deletions
+35 -24
View File
@@ -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
+3 -3
View File
@@ -4,7 +4,7 @@ name: benevoles
# côté de ce fichier (non versionné) : POSTGRES_USER, POSTGRES_PASSWORD,
# POSTGRES_DB, JWT_SECRET, PUBLIC_BASE_URL et les variables SMTP_* / EMAIL_ENABLED.
# BACKEND_IMAGE / FRONTEND_IMAGE sont exportées par le pipeline de déploiement
# (.gitlab-ci.yml).
# (.gitea/workflows/ci-cd.yml).
#
# Les deux services ne publient que sur `127.0.0.1` : c'est le Caddy du VPS
# (hors de ce compose, voir deploy/README.md) qui reçoit le trafic public et
@@ -27,7 +27,7 @@ services:
retries: 10
backend:
image: ${BACKEND_IMAGE:-registry.gitlab.com/OWNER/REPO/backend:latest}
image: ${BACKEND_IMAGE:-gitea.mon-domaine.fr/OWNER/REPO/backend:latest}
environment:
DATABASE_URL: postgresql+psycopg://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
ENVIRONMENT: production
@@ -50,7 +50,7 @@ services:
restart: unless-stopped
frontend:
image: ${FRONTEND_IMAGE:-registry.gitlab.com/OWNER/REPO/frontend:latest}
image: ${FRONTEND_IMAGE:-gitea.mon-domaine.fr/OWNER/REPO/frontend:latest}
depends_on:
- backend
ports: