Le groupement par template_id etait faux sur la prod :
- Les doublons historiques ont template_id=NULL (crees avant la migration)
- Deux glossaires 'Finance - FR->Anglais' et 'Finance - FR->Multilingue'
partagent le meme template_id mais DOIVENT etre conserves separement.
Changements :
- Groupement par (user_id, name) -> c'est ce que l'utilisateur voit dans l'UI
et la definition reelle d'un doublon.
- Les glossaires multilingues ('-> Multilingue') ont un nom distinct des
versions '-> Anglais' : ils ne sont jamais fusionnes (preserve par design).
- Fallback automatique si la colonne template_id est absente du schema
(dev DB) : warning + requete sans la colonne, aucun crash.
- Suppression du flag --allow-missing-template-id devenu inutile.
- Nettoyage des imports ORM inutiles (text brut uniquement, plus rapide).
- scripts/backup_duplicate_glossaries.py : exporte en JSON les doublons
(meme user_id + template_id) sans rien supprimer. Schema validation,
tri stable, mode degrade si colonne template_id absente.
- scripts/delete_duplicate_glossaries.py : lit un backup JSON et supprime
les doublons listes. Validation IDs, confirmation interactive,
commit par user, mode --dry-run / --yes.
- .gitea/workflows/cleanup-glossaries.yml : workflow_dispatch qui SSH
sur le serveur de prod et execute le script dans le conteneur backend
(postgres demarre, .env charge, env_file docker-compose).
Three fixes to ensure alembic migrations always run in production:
1. entrypoint.sh: add `exec "$@"` passthrough so `docker compose run
--rm backend alembic upgrade head` actually runs alembic instead of
ignoring args and starting uvicorn.
2. entrypoint.sh: remove `|| echo` fallback on alembic — if migration
fails the container must stop, not silently continue.
3. deploy.yml: start only postgres+redis first, run migration, THEN
start backend. Previously the backend started before migration,
ran with stale schema, and the separate migration step was broken
by the entrypoint bug.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
8-step pipeline:
1. Git pull
2. pg_dumpall + gzip backup (keep last 10)
3. Build images (with cache)
4. Start services
5. Wait for postgres
6. Run alembic migration (one-shot container)
- On failure: auto-restore DB from backup
7. Health check backend
- On failure: auto-rollback DB + restart
8. Summary with backup path
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Use 'docker compose run --rm backend alembic upgrade head' to run
migration in a throwaway container (doesn't need backend running)
- Restore entrypoint migration fallback (don't block startup)
- Restart backend after migration to pick up schema changes
- Remove --no-cache (too slow, was causing timeouts)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Entrypoint migration can fail silently. Now runs explicitly:
1. Wait for postgres
2. alembic upgrade head (explicit, fails the deploy if broken)
3. Wait for backend healthy
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
All services (app + Prometheus + Grafana + node-exporter + cAdvisor)
are now in a single docker-compose.yml. One `docker compose up -d`
starts everything. No more separate monitoring file needed.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Monitoring was in a separate blocked job. Now everything runs in one
SSH session so Prometheus + Grafana always deploy with the app.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Use ubuntu-24.04 runner with SSH to 192.168.1.151 (same pattern as
memento project). Self-hosted runner is not needed on the server.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Auto-deploys to 192.168.1.151 on push to production-deployment:
- Builds backend and frontend Docker images
- Starts all services with health checks
- Optionally deploys monitoring stack
- Cleans up old images
Requires a self-hosted runner on the target server.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
