SLP_Software/SlpSoftware
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Consistente _TEST/_PRODUCTION postfix voor omgevingsspecifieke Gitea variables
Continuous Integration / config (pull_request) Successful in 10s
Details
Continuous Integration / prepare (pull_request) Successful in 1m14s
Details
Continuous Integration / build-production (pull_request) Skipped
Details
Continuous Integration / build (pull_request) Successful in 1m56s
Details
Continuous Integration / test (pull_request) Successful in 1m48s
Details
Continuous Integration / deploy-test (pull_request) Skipped
Details
Continuous Integration / deploy-production (pull_request) Skipped
Details

Browse Source 
Hernoemt de Gitea-variable achter VITE_UMAMI_WEBSITE_ID naar
VITE_UMAMI_WEBSITE_ID_TEST, zodat deze consistent is met
VITE_UMAMI_WEBSITE_ID_PRODUCTION en DEPLOY_PATH_TEST/DEPLOY_PATH_PRODUCTION.
De Vite build-time envvar-naam die de app zelf verwacht
(VITE_UMAMI_WEBSITE_ID) verandert niet, alleen de naam van de Gitea
repository variable erachter. Bewust gedeelde variabelen (VITE_UMAMI_SCRIPT_URL,
VITE_SENTRY_DSN, PI_MAIN_* secrets) krijgen geen postfix, want die zijn
geen omgevingsspecifieke waarden. Documentatie in umami-setup.md,
deployment-instructions.md en monitoring-plan.md bijgewerkt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Sluijsens
2026-07-27 12:16:10 +02:00
co-authored by Claude Sonnet 5
parent 4bddcbbc50
commit 3af15159fe
4 changed files with 22 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md
+1 -1
View File
@@ -28,7 +28,7 @@ A combination of:
## Open Action Items
1. ~~Decide logging destination~~ — **Resolved and verified**: Sentry free tier, wired into `ErrorBoundary`/`main.tsx` (see `monitoring-setup.md`), including tracing, environment/release tags, and a tunnel to bypass ad-blocker blocking. The user confirmed errors, logs, and metrics are received correctly, both locally and on the test environment. The Gitea Actions variable `VITE_SENTRY_DSN` still needs to be created by the user with a real Sentry project DSN for the test/production build; until then that build simply skips Sentry initialization and only console-logging is active (local development already has its own DSN via `.env.local`).
2. ~~Pick concrete analytics + uptime tools~~ — **Resolved**: self-hosted Umami + UptimeRobot (see `monitoring-setup.md` and `umami-setup.md`). Remaining manual follow-ups: actually deploying the Umami containers on the Pi, registering DNS/SSL for `analytics.slpsoftware.nl`, creating the UptimeRobot monitor, and setting the `VITE_UMAMI_SCRIPT_URL`/`VITE_UMAMI_WEBSITE_ID` Gitea repository variables.
2. ~~Pick concrete analytics + uptime tools~~ — **Resolved**: self-hosted Umami + UptimeRobot (see `monitoring-setup.md` and `umami-setup.md`). Remaining manual follow-ups: actually deploying the Umami containers on the Pi, registering DNS/SSL for `analytics.slpsoftware.nl`, creating the UptimeRobot monitor, and setting the `VITE_UMAMI_SCRIPT_URL`/`VITE_UMAMI_WEBSITE_ID_TEST` (and, once production is set up, `VITE_UMAMI_WEBSITE_ID_PRODUCTION`) Gitea repository variables.
## Rationale
Given this is a simple static marketing site with no backend and no existing monitoring, the aim is lightweight, low/no-cost observability: enough to know if the site is down (uptime) and how it's being used (analytics), plus a documented (if not yet finalized) path for capturing client-side errors. Alerting was deliberately left out to avoid over-engineering a notification pipeline before there's a concrete trigger/audience for it.