Hernoem PI_MAIN_HOST secret naar PI_MAIN_ADDRESS

2026-07-30 13:32:42 +02:00
parent ecad3c3b4e
commit 6c08d0a842
4 changed files with 4 additions and 4 deletions
@@ -28,7 +28,7 @@ Voeg deze secrets toe in Gitea: **Repository → Settings → Actions → Secret

 | Secret | Waarde |
 |---|---|
-| `PI_MAIN_HOST` | Intern IP-adres van de webserver-Pi (`192.168.1.103`) |
+| `PI_MAIN_ADDRESS` | Intern IP-adres van de webserver-Pi (`192.168.1.103`) |
 | `PI_MAIN_PORT` | SSH-poort (`2224`) |
 | `PI_MAIN_USERNAME` | SSH-gebruikersnaam (`webadmin`) |
 | `PI_MAIN_PASSWORD` | Het SSH-wachtwoord van deze gebruiker |
@@ -27,7 +27,7 @@ Zie `rollback-plan.md` — voor de testomgeving kan een eerdere commit/branch op

 ## Secrets & Configuration
 Voor de testomgeving zijn de volgende Gitea Actions Secrets (repository-niveau) vereist:
- `PI_MAIN_HOST` — `192.168.1.103` (intern IP van de webserver-Pi)
+- `PI_MAIN_ADDRESS` — `192.168.1.103` (intern IP van de webserver-Pi)
 - `PI_MAIN_PORT` — `2224`
 - `PI_MAIN_USERNAME` — `webadmin`
 - `PI_MAIN_PASSWORD` — het SSH-wachtwoord van deze gebruiker
@@ -11,7 +11,7 @@

 ## Additional Readiness Items
 - **Backups**: N/A — this unit is a static marketing site (`dist/` bundle) with no database and no server-side/persistent state; nothing to back up beyond the source repository itself, which is already under git version control.
- **Secrets Management**: Configured — host credentials (`PI_MAIN_HOST`/`PORT`/`USERNAME`/`PASSWORD`) are stored as Gitea Actions Secrets (never committed to the repo) and reused for both test and production deploys, since both target the same host for now; see `deployment-instructions.md`.
+- **Secrets Management**: Configured — host credentials (`PI_MAIN_ADDRESS`/`PORT`/`USERNAME`/`PASSWORD`) are stored as Gitea Actions Secrets (never committed to the repo) and reused for both test and production deploys, since both target the same host for now; see `deployment-instructions.md`.
 - **Runbook/Support Handover**: Partially covered — `operations/deployment/deployment-instructions.md` and `operations/deployment/rollback-plan.md` document how to trigger a release, upload the build, and roll back. No separate incident-response runbook exists beyond these documents, which is proportionate given this is a single-owner static site with no backend to page someone about.
 - **Alert Ownership**: N/A — Alerting was explicitly declared out of scope in Monitoring Setup, so there is no alert-on-call/ownership rotation to define. If the chosen uptime dashboard tool (UptimeRobot/Better Uptime) is configured with its own opportunistic e-mail notification, the site owner is the sole recipient.