Voeg Sentry-foutregistratie toe als gekozen logging-bestemming
Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
Junie
@@ -13,7 +13,7 @@ Initial answers to the monitoring plan were contradictory: Question 2 selected "
|
||||
## Chosen Approach(es)
|
||||
|
||||
### Logging
|
||||
Client-side errors (JavaScript crashes, broken links) should be logged, but the concrete destination is not yet decided (original Question 3 = C, "not yet determined"). This is tracked as an **open action item** below rather than blocking this stage.
|
||||
Client-side errors (JavaScript crashes, broken links) are logged. **Decided**: Sentry free tier (in addition to the browser console) — see the follow-up in `audit.md` and the implementation in `monitoring-setup.md`.
|
||||
|
||||
### Dashboards
|
||||
A combination of:
|
||||
@@ -27,7 +27,7 @@ A combination of:
|
||||
- **Reuse of existing infrastructure**: this feature does not plug into any pre-existing shared monitoring (original Question 7 = A) — there is none yet. Should a shared back-end/CMS monitoring stack be introduced later, this can be revisited.
|
||||
|
||||
## Open Action Items
|
||||
1. **Decide logging destination**: choose between "browser console only" (no central storage, manual debugging) or a free/low-cost external error-tracking service (e.g. Sentry free tier) once this becomes a priority. Until decided, `monitoring-setup.md` documents both options so either can be adopted without re-doing this stage.
|
||||
1. ~~Decide logging destination~~ — **Resolved**: Sentry free tier, wired into `ErrorBoundary`/`main.tsx` (see `monitoring-setup.md`). The Gitea Actions variable `VITE_SENTRY_DSN` still needs to be created by the user with a real Sentry project DSN; until then the build simply skips Sentry initialization and only console-logging is active.
|
||||
2. **Pick concrete analytics + uptime tools**: `monitoring-setup.md` lists candidate free-tier tools; final tool selection/account creation is a manual follow-up outside this workflow (no code changes required to swap providers, since neither is wired into the codebase yet beyond an optional embed snippet).
|
||||
|
||||
## Rationale
|
||||
|
||||
@@ -9,16 +9,17 @@ Concrete setup steps for the approaches chosen in `monitoring-plan.md`: **Loggin
|
||||
- Broken/failed navigation (e.g. an unexpected router error).
|
||||
- No user PII, form input, or sensitive data should ever be logged — this is a public marketing site, but keep this discipline regardless.
|
||||
|
||||
### Destination — open decision
|
||||
The destination was not finalized (original Question 3 = C). Two supported options, either of which can be adopted later without further design work:
|
||||
### Destination — decided: Sentry free tier + console
|
||||
Both the console and Sentry are now active (original Question 3 resolved as a combination):
|
||||
|
||||
**Option 1: Browser console only (default today)**
|
||||
- No code changes needed — errors already surface via `console.error` inside the existing `ErrorBoundary`.
|
||||
- Zero cost, but not centrally visible; only useful for manual debugging (e.g. via a user's screenshot or a support request).
|
||||
**Console (always on)**
|
||||
- Errors already surface via `console.error` inside `ErrorBoundary.componentDidCatch` — unchanged, zero cost, useful for local/manual debugging.
|
||||
|
||||
**Option 2: External error-tracking service (e.g. Sentry free tier)**
|
||||
- When decided, add `@sentry/react` as a dependency, initialize it once in the app entry point (e.g. `src/main.tsx`) with the project DSN, and report caught errors from the `ErrorBoundary`'s `componentDidCatch`/`onError` hook to Sentry in addition to the console.
|
||||
- Store the DSN as a Gitea Actions variable (or a build-time `.env` value, since it's not a secret — Sentry DSNs are safe to expose client-side) and inject it via Vite's `import.meta.env`.
|
||||
**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).
|
||||
- `ErrorBoundary.componentDidCatch` calls `Sentry.captureException(error, { extra: { componentStack: info.componentStack } })` in addition to `console.error`.
|
||||
- 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.
|
||||
|
||||
**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.
|
||||
@@ -55,7 +56,7 @@ Pick one:
|
||||
|
||||
| Concern | Approach | Status |
|
||||
|---|---|---|
|
||||
| Client-side errors | Logging (console today; Sentry free tier optional later) | Destination open item |
|
||||
| Client-side errors | Logging (console + Sentry free tier) | Implemented; `VITE_SENTRY_DSN` Gitea variable still needs to be created by the user |
|
||||
| Visitor/usage insight | Analytics dashboard (Plausible/Umami/GA4) | Tool selection open item |
|
||||
| Site reachability | Uptime dashboard (UptimeRobot/Better Uptime) | Tool selection + production URL open item |
|
||||
| Alerting | Out of scope | Not configured |
|
||||
|
||||
@@ -19,6 +19,6 @@
|
||||
- **Ready for Production**: Yes with caveats
|
||||
- **Open Follow-ups**:
|
||||
- Finalize the hosting/domain setup and extend `.gitea/workflows/deploy.yml`'s `deploy` job to actually upload `dist/` to the host, instead of only packaging it as a downloadable artifact (see `deployment-plan.md` "Open Item")
|
||||
- Decide the client-side error logging destination (browser console only vs. an external service such as Sentry free tier) — see `monitoring-setup.md`
|
||||
- ~~Decide the client-side error logging destination~~ — **Resolved**: console + Sentry free tier, implemented (see `monitoring-setup.md`); remaining manual step is creating the `VITE_SENTRY_DSN` Gitea Actions variable
|
||||
- Pick and configure the concrete analytics tool (e.g. Plausible/Umami/GA4) and uptime dashboard tool (e.g. UptimeRobot/Better Uptime), including registering the final production URL once hosting is finalized
|
||||
- Run a formal Lighthouse performance check before the first real production deployment (flagged as not yet run in `build-and-test-summary.md`)
|
||||
|
||||
Reference in New Issue
Block a user