From 3af15159fea1b0cde8d86690c17f63a481a8fe46 Mon Sep 17 00:00:00 2001 From: Sluijsens Date: Mon, 27 Jul 2026 12:16:10 +0200 Subject: [PATCH] Consistente _TEST/_PRODUCTION postfix voor omgevingsspecifieke Gitea variables 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 --- .gitea/workflows/continuous_integration.yaml | 7 +++++- .../deployment/deployment-instructions.md | 2 +- .../operations/monitoring/monitoring-plan.md | 2 +- .../operations/monitoring/umami-setup.md | 23 +++++++++++-------- 4 files changed, 22 insertions(+), 12 deletions(-) diff --git a/.gitea/workflows/continuous_integration.yaml b/.gitea/workflows/continuous_integration.yaml index d8330b0..24637b6 100644 --- a/.gitea/workflows/continuous_integration.yaml +++ b/.gitea/workflows/continuous_integration.yaml @@ -112,7 +112,12 @@ jobs: - name: Build env: VITE_UMAMI_SCRIPT_URL: ${{ vars.VITE_UMAMI_SCRIPT_URL }} - VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID }} + # Gitea-variable heet VITE_UMAMI_WEBSITE_ID_TEST (niet zonder suffix), + # analoog aan VITE_UMAMI_WEBSITE_ID_PRODUCTION in de build-production + # job hieronder. Linkerkant (VITE_UMAMI_WEBSITE_ID) is wél altijd + # gelijk: dat is de Vite-buildtime-envvar-naam die de app verwacht + # (zie src/components/UmamiAnalytics.tsx), niet aan te passen. + VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID_TEST }} # Sentry DSN is niet gevoelig (veilig om in de client-bundle te zitten), # daarom een Gitea Actions "vars"-waarde i.p.v. een secret. Optioneel: # als deze niet is ingesteld, wordt Sentry-logging simpelweg overgeslagen diff --git a/aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md b/aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md index dec63d7..175a6a3 100644 --- a/aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md +++ b/aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md @@ -86,4 +86,4 @@ Vereist eenmalig vooraf: ## Future Work - **Van wachtwoord naar SSH-key**: vervang `sshpass -p "${{ secrets.PI_MAIN_PASSWORD }}" scp ...` in `deploy.yaml` door een `scp`-commando met `-i ` (een nieuwe secret `PI_MAIN_SSH_KEY` die je eerst als bestand wegschrijft in de run-stap), en zet de bijbehorende public key in `~/.ssh/authorized_keys` van de `webadmin`-gebruiker op de webserver-Pi. Verwijder daarna het wachtwoord-secret. - **Productie nginx/SSL-configuratie**: de deploy-pipeline ondersteunt productie al (`build-production`/`deploy-production`), maar er is nog geen productie-nginx-voorbeeldconfiguratie — deze is op verzoek van de gebruiker verwijderd totdat er een goed-werkende versie is, en kan later opnieuw opgebouwd worden naar analogie van `nginx/webserver-nginx.conf.example` en `nginx/reverse-proxy-nginx.conf.example`, met domein `slpsoftware.nl`. -- **Aparte productie-Umami-website/Sentry-project**: `build-production` gebruikt momenteel dezelfde `VITE_UMAMI_WEBSITE_ID`/`VITE_SENTRY_DSN` als de testbuild. Overweeg dit te splitsen zodra test- en productieverkeer niet meer door elkaar gemengd mogen worden in dezelfde analytics/Sentry-projecten. +- **Apart productie-Sentry-project**: `build-production` gebruikt momenteel dezelfde `VITE_SENTRY_DSN` als de testbuild (Umami heeft al aparte website-ID's per omgeving, zie `umami-setup.md`). Overweeg dit te splitsen zodra test- en productie-events niet meer door elkaar gemengd mogen worden in hetzelfde Sentry-project. diff --git a/aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md b/aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md index 11e4bf0..48a26de 100644 --- a/aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md +++ b/aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md @@ -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. diff --git a/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md b/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md index 93ebab3..4e3aab6 100644 --- a/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md +++ b/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md @@ -192,7 +192,7 @@ verschillende domeinen en horen dus niet in dezelfde statistieken te belanden: - Name: `SLP Software (test)` (of naar keuze) - Domain: `test.slpsoftware.nl` 3. Na het opslaan toont Umami een **Website ID** (een UUID) voor deze entry — nodig voor - `VITE_UMAMI_WEBSITE_ID` in de volgende stap. + `VITE_UMAMI_WEBSITE_ID_TEST` in de volgende stap. 4. Herhaal stap 2-3 voor productie zodra die omgeving wordt opgezet: een tweede website- entry met Domain `slpsoftware.nl`, met een eigen Website ID voor `VITE_UMAMI_WEBSITE_ID_PRODUCTION`. @@ -201,20 +201,25 @@ verschillende domeinen en horen dus niet in dezelfde statistieken te belanden: De React-app (`src/components/UmamiAnalytics.tsx`) injecteert het Umami tracking-script automatisch, mits de volgende build-time variabelen zijn ingesteld — geen van deze zijn **secrets** (client-side zichtbaar), dus als Gitea Actions **repository variables** -(niet secrets), net als `VITE_SENTRY_DSN`: +(niet secrets), net als `VITE_SENTRY_DSN`. Omgevingsspecifieke variabelen (die per +omgeving een andere waarde hebben) krijgen consistent een `_TEST`/`_PRODUCTION`-postfix; +gedeelde variabelen (die bewust voor beide omgevingen identiek zijn) niet: | Variabele | Waarde | |---|---| -| `VITE_UMAMI_SCRIPT_URL` | `https://analytics.slpsoftware.nl/script.js` (gedeeld tussen test en productie — zelfde Umami-instance/endpoint voor beide) | -| `VITE_UMAMI_WEBSITE_ID` | het Website ID van de **test**-website-entry uit stap 4 | +| `VITE_UMAMI_SCRIPT_URL` | `https://analytics.slpsoftware.nl/script.js` (gedeeld tussen test en productie — zelfde Umami-instance/endpoint voor beide, geen postfix) | +| `VITE_UMAMI_WEBSITE_ID_TEST` | het Website ID van de **test**-website-entry uit stap 4 | | `VITE_UMAMI_WEBSITE_ID_PRODUCTION` | het Website ID van de **productie**-website-entry uit stap 4 (pas nodig vóór de eerste `deploy_production`-run) | Stel deze in via **Gitea → Repository Settings → Actions → Variables**. Zodra ze bestaan, pakt de eerstvolgende build ze automatisch op; zonder deze variabelen slaat de app het -inladen van het script gewoon over (geen crash, geen tracking). Let op: -`continuous_integration.yaml`'s `build`-job (test) leest `VITE_UMAMI_WEBSITE_ID`, de -`build-production`-job leest `VITE_UMAMI_WEBSITE_ID_PRODUCTION` — verwissel deze niet, -anders komt productieverkeer in de teststatistieken terecht (of andersom). +inladen van het script gewoon over (geen crash, geen tracking). Let op: dit zijn de +namen van de Gitea-variabelen — de app zelf verwacht altijd de envvar-naam +`VITE_UMAMI_WEBSITE_ID` (zie `UmamiAnalytics.tsx`), dus in `continuous_integration.yaml` +wordt bv. `VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID_TEST }}` gebruikt in de +`build`-job en `VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID_PRODUCTION }}` in +`build-production` — verwissel deze niet, anders komt productieverkeer in de +teststatistieken terecht (of andersom). **Lokaal (`pnpm dev`)**: het tracking-script wordt hier bewust nooit geladen (zie `UmamiAnalytics.tsx`), zodat lokaal testen de bezoekersstatistieken niet vervuilt. Wil je @@ -229,7 +234,7 @@ dit toch lokaal testen, zet dan tijdelijk beide waarden in `.env.local` (zie - [ ] DNS-record + certbot voor `analytics.slpsoftware.nl` op de reverse-proxy-Pi. - [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login. - [ ] Website aanmaken in Umami voor de testomgeving en het Website ID overnemen. -- [ ] `VITE_UMAMI_SCRIPT_URL` en `VITE_UMAMI_WEBSITE_ID` als Gitea repository variables instellen. +- [ ] `VITE_UMAMI_SCRIPT_URL` en `VITE_UMAMI_WEBSITE_ID_TEST` als Gitea repository variables instellen. - [ ] Zodra productie wordt opgezet: aparte website aanmaken in Umami voor `slpsoftware.nl` en het Website ID als `VITE_UMAMI_WEBSITE_ID_PRODUCTION` instellen (zie stap 4/5 hierboven — vereist vóór de eerste `deploy_production`-run). ## Vervolgstappen voor toekomstige self-hosted diensten