MALIO-DEV/Inventory
3
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases 2 Wiki Activity

feat(infra) : branche le SDK Sentry (back + front) vers GlitchTip #7

Merged
matthieu merged 3 commits from feat/glitchtip-error-tracking into develop 2026-06-29 14:17:29 +00:00
Conversation 1 Commits 3 Files Changed 15
+1385 -26
matthieu commented 2026-06-29 10:55:20 +00:00
Owner
Copy Link
Copy Source

Objectif

Brancher le SDK Sentry (back + front) d'Inventory vers l'instance GlitchTip auto-hébergée — error tracking centralisé du ticket INFRA #146. Les erreurs back (Symfony) et front (Nuxt) remontent comme issues groupées par projet.

Pattern calqué sur l'intégration existante de Lesstime (référence), avec une adaptation propre à Inventory.

Backend (Symfony)

  • composer require sentry/sentry-symfony:^5.10, bundle enregistré prod-only (config/bundles.php)
  • config/packages/sentry.yaml : handler Monolog niveau ERROR+, register_error_listener: false (évite les doublons avec Monolog), ignore les 4xx / AccessDeniedException, pas d'APM (traces_sample_rate: 0), release: %app.version%
  • config/services.yaml importe version.yaml → expose app.version au container (adaptation Inventory : ce paramètre n'était pas câblé côté back, contrairement à Lesstime ; sans ça la compilation prod échouait)
  • .env : bloc SENTRY_DSN documenté, vide par défaut → SDK inerte

Frontend (Nuxt)

  • @sentry/nuxt@^10.61 ; module chargé uniquement si NUXT_PUBLIC_SENTRY_DSN est défini (zéro overhead en dev)
  • runtimeConfig.public.sentry + sourcemap: { client: 'hidden' } + options d'upload des source maps (fournies au build via secrets CI)
  • sentry.client.config.ts : init côté client gardée par if (dsn)

Sécurité

Aucun secret commité. Tous les DSN sont vides par défaut → rien n'est envoyé tant que la prod n'est pas configurée.

Vérifications

  • ✅ Container prod compile (cache:clear --env=prod), app.version = 1.9.49 enregistré
  • ✅ Typecheck front : 0 nouvelle erreur introduite par cette branche
  • ✅ php-cs-fixer propre

Reste à faire (déploiement, hors code)

  1. Créer les 2 projets GlitchTip inventory-api et inventory-front → récupérer les DSN
  2. En prod (non commité) :
    • Back runtime : SENTRY_DSN=…
    • Front build : NUXT_PUBLIC_SENTRY_DSN=… + SENTRY_URL / SENTRY_ORG / SENTRY_PROJECT / SENTRY_AUTH_TOKEN

🤖 Generated with Claude Code

## Objectif Brancher le **SDK Sentry (back + front)** d'Inventory vers l'instance **GlitchTip** auto-hébergée — error tracking centralisé du ticket INFRA **#146**. Les erreurs back (Symfony) et front (Nuxt) remontent comme *issues* groupées par projet. Pattern calqué sur l'intégration existante de **Lesstime** (référence), avec une adaptation propre à Inventory. ## Backend (Symfony) - `composer require sentry/sentry-symfony:^5.10`, bundle enregistré **prod-only** (`config/bundles.php`) - `config/packages/sentry.yaml` : handler Monolog niveau **ERROR+**, `register_error_listener: false` (évite les doublons avec Monolog), ignore les 4xx / `AccessDeniedException`, **pas d'APM** (`traces_sample_rate: 0`), `release: %app.version%` - `config/services.yaml` importe `version.yaml` → expose `app.version` au container *(adaptation Inventory : ce paramètre n'était pas câblé côté back, contrairement à Lesstime ; sans ça la compilation prod échouait)* - `.env` : bloc `SENTRY_DSN` documenté, **vide par défaut → SDK inerte** ## Frontend (Nuxt) - `@sentry/nuxt@^10.61` ; module chargé **uniquement si `NUXT_PUBLIC_SENTRY_DSN`** est défini (zéro overhead en dev) - `runtimeConfig.public.sentry` + `sourcemap: { client: 'hidden' }` + options d'upload des source maps (fournies au build via secrets CI) - `sentry.client.config.ts` : init côté client gardée par `if (dsn)` ## Sécurité Aucun secret commité. **Tous les DSN sont vides par défaut** → rien n'est envoyé tant que la prod n'est pas configurée. ## Vérifications - ✅ Container **prod compile** (`cache:clear --env=prod`), `app.version` = 1.9.49 enregistré - ✅ Typecheck front : **0 nouvelle erreur** introduite par cette branche - ✅ `php-cs-fixer` propre ## Reste à faire (déploiement, hors code) 1. Créer les 2 projets GlitchTip **`inventory-api`** et **`inventory-front`** → récupérer les DSN 2. En **prod** (non commité) : - Back runtime : `SENTRY_DSN=…` - Front build : `NUXT_PUBLIC_SENTRY_DSN=…` + `SENTRY_URL` / `SENTRY_ORG` / `SENTRY_PROJECT` / `SENTRY_AUTH_TOKEN` 🤖 Generated with [Claude Code](https://claude.com/claude-code)
matthieu added 1 commit 2026-06-29 10:55:21 +00:00
feat(infra) : branche le SDK Sentry (back + front) vers GlitchTip 517aefcd9b 
Error tracking centralisé (ticket INFRA #146) : remontée des erreurs back
(Symfony) et front (Nuxt) vers l'instance GlitchTip auto-hébergée.

Backend :
- sentry/sentry-symfony ^5.10, bundle enregistré prod-only
- config/packages/sentry.yaml : handler Monolog niveau ERROR+, ignore les
  4xx/AccessDenied, pas d'APM, release = %app.version%
- services.yaml importe version.yaml pour exposer app.version au container
- .env : bloc SENTRY_DSN documenté (vide => SDK inerte)

Frontend :
- @sentry/nuxt ^10.61, module chargé uniquement si NUXT_PUBLIC_SENTRY_DSN défini
- runtimeConfig.public.sentry + source maps (hidden) + options d'upload
- sentry.client.config.ts : init côté client gardée par if (dsn)

DSN vides par défaut : aucune erreur n'est envoyée tant que les projets
GlitchTip inventory-api / inventory-front et leurs DSN ne sont pas configurés
en prod. Aucun secret commité.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
matthieu commented 2026-06-29 10:59:36 +00:00
Author
Owner
Copy Link
Copy Source

📋 Étapes restantes pour activer l'error tracking en prod

Cette PR fait le branchement applicatif (SDK back + front). Reste le plumbing déploiement + la config, à faire dans 3 zones.

1. ENV (fichiers / serveur)

Variable Où Côté Valeur
SENTRY_DSN infra/prod/.env sur le serveur (env_file du compose, non versionné) Back runtime DSN du projet GlitchTip inventory-api
NUXT_PUBLIC_SENTRY_DSN build-arg (Dockerfile/CI) Front build DSN du projet inventory-front
SENTRY_URL / SENTRY_ORG / SENTRY_PROJECT / SENTRY_AUTH_TOKEN build-arg (Dockerfile/CI) Front build upload des source maps

⚠️ Tant que ces DSN sont vides, le SDK est inerte (rien envoyé) — aucun risque à merger.

2. PROD (serveur + GlitchTip)

  1. Dans GlitchTip (https://logs.malio-dev.fr) → créer 2 projets : inventory-api (php-symfony) et inventory-front (javascript-vue) → noter les 2 DSN.
  2. Sur le serveur, éditer infra/prod/.env (à côté du docker-compose.yml) et ajouter SENTRY_DSN=<DSN inventory-api>.
  3. Déployer : ./deploy.sh <tag> → le back commence à remonter ses erreurs immédiatement.

3. GITEA (CI + secrets + merge)

⚠️ Plumbing front manquant — sans ça inventory-front ne recevra jamais son DSN :

  • infra/prod/Dockerfile (stage frontend-build, avant npm run generate) : ajouter
    ARG/ENV pour NUXT_PUBLIC_SENTRY_DSN, SENTRY_URL, SENTRY_ORG, SENTRY_PROJECT, SENTRY_AUTH_TOKEN.
  • .gitea/workflows/build-docker.yml : ajouter les --build-arg ...=${{ secrets.* }} au docker build.
  • Repo → Settings → Actions → Secrets : créer INVENTORY_SENTRY_DSN_FRONT, SENTRY_URL, SENTRY_ORG, SENTRY_PROJECT, SENTRY_AUTH_TOKEN.

Puis : merger cette PR dans develop → sync develop → master → tag vX.Y.Z (déclenche build-docker.yml qui build + push l'image).

Ordre conseillé : (2.1 créer projets GlitchTip) → (3 Dockerfile+CI+secrets) → merge+tag → (2.2 SENTRY_DSN serveur) → deploy.

## 📋 Étapes restantes pour activer l'error tracking en prod Cette PR fait le **branchement applicatif** (SDK back + front). Reste le plumbing déploiement + la config, à faire dans 3 zones. ### 1. ENV (fichiers / serveur) | Variable | Où | Côté | Valeur | |---|---|---|---| | `SENTRY_DSN` | `infra/prod/.env` **sur le serveur** (env_file du compose, non versionné) | Back runtime | DSN du projet GlitchTip `inventory-api` | | `NUXT_PUBLIC_SENTRY_DSN` | **build-arg** (Dockerfile/CI) | Front build | DSN du projet `inventory-front` | | `SENTRY_URL` / `SENTRY_ORG` / `SENTRY_PROJECT` / `SENTRY_AUTH_TOKEN` | **build-arg** (Dockerfile/CI) | Front build | upload des source maps | > ⚠️ Tant que ces DSN sont vides, le SDK est **inerte** (rien envoyé) — aucun risque à merger. ### 2. PROD (serveur + GlitchTip) 1. Dans GlitchTip (`https://logs.malio-dev.fr`) → créer 2 projets : **`inventory-api`** (php-symfony) et **`inventory-front`** (javascript-vue) → noter les 2 DSN. 2. Sur le serveur, éditer `infra/prod/.env` (à côté du `docker-compose.yml`) et ajouter `SENTRY_DSN=<DSN inventory-api>`. 3. Déployer : `./deploy.sh <tag>` → le **back** commence à remonter ses erreurs immédiatement. ### 3. GITEA (CI + secrets + merge) ⚠️ **Plumbing front manquant** — sans ça `inventory-front` ne recevra jamais son DSN : - **`infra/prod/Dockerfile`** (stage `frontend-build`, avant `npm run generate`) : ajouter `ARG`/`ENV` pour `NUXT_PUBLIC_SENTRY_DSN`, `SENTRY_URL`, `SENTRY_ORG`, `SENTRY_PROJECT`, `SENTRY_AUTH_TOKEN`. - **`.gitea/workflows/build-docker.yml`** : ajouter les `--build-arg ...=${{ secrets.* }}` au `docker build`. - **Repo → Settings → Actions → Secrets** : créer `INVENTORY_SENTRY_DSN_FRONT`, `SENTRY_URL`, `SENTRY_ORG`, `SENTRY_PROJECT`, `SENTRY_AUTH_TOKEN`. Puis : **merger cette PR dans `develop`** → sync `develop → master` → tag `vX.Y.Z` (déclenche `build-docker.yml` qui build + push l'image). --- **Ordre conseillé** : (2.1 créer projets GlitchTip) → (3 Dockerfile+CI+secrets) → merge+tag → (2.2 `SENTRY_DSN` serveur) → deploy.
matthieu added 1 commit 2026-06-29 11:02:58 +00:00
feat(infra) : injecte les DSN Sentry au build prod (Dockerfile + CI Gitea) d3f1e95711 
Complète le branchement Sentry/GlitchTip côté déploiement pour que le front
reçoive son DSN et uploade ses source maps en prod.

- infra/prod/Dockerfile (stage frontend-build) : ARG NUXT_PUBLIC_SENTRY_DSN +
  SENTRY_URL/ORG/PROJECT/AUTH_TOKEN, passés en préfixe inline du RUN npm run
  generate (pas en ENV → token non persisté ; stage intermédiaire jeté de toute
  façon). Vides par défaut => module Sentry inerte, pas d'upload.
- .gitea/workflows/build-docker.yml : --build-arg depuis les secrets Gitea
  (INVENTORY_SENTRY_DSN_FRONT, SENTRY_URL, SENTRY_ORG, SENTRY_PROJECT,
  SENTRY_AUTH_TOKEN).
- infra/prod/.env.example : documente SENTRY_DSN (back, runtime).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
matthieu added 1 commit 2026-06-29 11:15:26 +00:00
chore(mcp) : retire l'override lesstime du .mcp.json (utilise la conf globale) 746578c2cf 
Le serveur MCP lesstime était redéfini en HTTP (405) ; on s'appuie désormais
sur la conf user globale (~/.claude.json, HTTPS) comme les autres projets.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
matthieu merged commit add6129ee5 into develop 2026-06-29 14:17:29 +00:00
matthieu deleted branch feat/glitchtip-error-tracking 2026-06-29 14:17:29 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
malio (admin malio) matthieu (THOLOT DECHENE Matthieu) tristan (Autin )
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MALIO-DEV/Inventory#7
Delete Branch "feat/glitchtip-error-tracking"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?