Voeg tracing en environment/release-tags toe aan Sentry-configuratie
Continuous Integration / config (pull_request) Successful in 11s
Continuous Integration / prepare (pull_request) Successful in 1m17s
Continuous Integration / build (pull_request) Successful in 2m10s
Continuous Integration / test (pull_request) Successful in 1m58s
Continuous Integration / deploy-test (pull_request) Skipped

Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
2026-07-25 13:35:09 +02:00
co-authored by Junie
parent 7680feb29f
commit 524b5a6dc7
7 changed files with 38 additions and 3 deletions
@@ -16,11 +16,14 @@ Both the console and Sentry are now active (original Question 3 resolved as a co
- Errors already surface via `console.error` inside `ErrorBoundary.componentDidCatch` — unchanged, zero cost, useful for local/manual debugging.
**Sentry free tier (implemented)**
- `@sentry/react` is a dependency; `src/main.tsx` calls `Sentry.init({ dsn: import.meta.env.VITE_SENTRY_DSN })` at startup, but only when a DSN is present — if not configured, Sentry is silently skipped and only console-logging remains active (safe default, no crash on missing config).
- `@sentry/react` is a dependency; `src/main.tsx` calls `Sentry.init({ ... })` at startup, but only when a DSN is present — if not configured, Sentry is silently skipped and only console-logging remains active (safe default, no crash on missing config).
- `ErrorBoundary.componentDidCatch` calls `Sentry.captureException(error, { extra: { componentStack: info.componentStack } })` in addition to `console.error`.
- **Tracing/performance** is also enabled (Sentry's recommended default alongside error monitoring, per the official React SDK setup guide): `tanstackRouterBrowserTracingIntegration(router)` is wired up so route navigations are captured as transactions, with `tracesSampleRate: 1.0` (capture all — appropriate for a low-traffic marketing site; lower this if traffic grows significantly).
- **Environment/release tagging**: `environment` is set to `import.meta.env.MODE` (e.g. `production`) and `release` is set to the app version from `package.json` (injected at build time via `vite.config.ts`'s `define: { __APP_VERSION__ }`), so events in Sentry can be filtered/grouped per environment and per shipped version.
- The DSN is injected at build time via Vite's `import.meta.env.VITE_SENTRY_DSN` (typed in `src/vite-env.d.ts`). It is **not** a secret (Sentry DSNs are safe to expose client-side), so it is passed as a **Gitea Actions repository variable** (`vars.VITE_SENTRY_DSN`, not a secret) to the `Build` step in `continuous_integration.yaml`.
- **Manual follow-up required**: create a free Sentry project (https://sentry.io) for this app, copy its DSN, and set it as the `VITE_SENTRY_DSN` repository variable in Gitea (Repository Settings → Actions → Variables). Until that variable is set, the build still succeeds and the site still works — Sentry reporting simply stays inactive.
- Free tier limits (error volume, retention) are typically sufficient for a low-traffic marketing site.
- **Not (yet) implemented, by explicit choice**: automatic source map upload (via `@sentry/vite-plugin`), which the official Sentry setup guide also recommends so stack traces show real source code instead of minified code. This requires a Sentry auth token/org/project as a new Gitea secret; deliberately left out of scope for now — revisit if readable production stack traces become a priority.
**Log level strategy**: only errors are logged (no verbose/info-level client logging) — this is a static site with no meaningful "business events" beyond page views, which are covered by analytics (see Dashboards below), not logging.