fix: permanent owner password persistence with SeedAudit guard
Root cause: Dual-source architecture for owner password (Gitea secret ENV_OWNER_PASSWORD vs host .env OWNER_PASSWORD) caused drift when the DB was ever re-seeded or the volume recreated. Changes: - Add SeedAudit entity + migration to track one-time seed operations - EnsureDatabaseAsync checks SeedAudit BEFORE seeding — owner is never re-created even if the Users table is wiped - Deploy and rollback workflows now read OWNER_PASSWORD from the host's persistent .env (single source of truth) instead of Gitea secrets - compose.yaml documented: OWNER_PASSWORD only used during initial seed - Cleanup: .gitignore extended for core dumps, changelog/deployment.md updated with 2026-06-20 session notes After this fix the DB is the single source of truth for the owner password after initial seed. The host .env is the single reference for the initial value.
This commit is contained in:
@@ -2,6 +2,25 @@
|
||||
|
||||
> Letzte Aktualisierung: 2026-06-20
|
||||
|
||||
- 2026-06-20: **Agent-Progress-Visibility live ausgerollt; normaler Gitea-Deploy-Trigger weiter defekt.**
|
||||
- Feature-Stand auf `main`: `adae7ba` (`feat: ship agent progress visibility`); nach CI-Blocker-Fix `2d21885` (`Fix activity repository test double`) war CI fuer Backend, Frontend und Security gruen.
|
||||
- Da `POST /actions/workflows/deploy.yaml/dispatches` serverseitig `HTTP 500` lieferte und fuer `2d21885` kein erfolgreicher Deploy-Run belegbar war, wurde der produktive Rollout manuell aus einem **sauberen Snapshot von Commit `2d21885`** durchgefuehrt statt aus dem schmutzigen lokalen Worktree.
|
||||
- Deploy-Pfad: Snapshot-Sync nach `/home/projekte_bao/openclaw/data/openclaw/workspace/nexus` und danach `docker compose --env-file .env up -d --build --force-recreate --wait`.
|
||||
- Verifikation: Host-Deploy-Pfad auf Git-HEAD `2d218853a5d198fa8521dadbb4c6ea9be19e191c`; `nexus-postgres-1`, `nexus-api-1`, `nexus-web-1` healthy; `https://nexus.noveria.net/health/live` = `200`; `/dashboard` = `200`; `/api/v1/operations/snapshot` = `401` ohne Auth; `GET /api/dashboard/tasks/caab972a-c46c-4af5-b2c4-9d31be824da3` liefert live `lastActivityMessage` und `lastActivityAt`.
|
||||
- Offener Betriebsblocker: Gitea-Deploy-Trigger / `workflow_dispatch` fuer `deploy.yaml` liefert weiter `HTTP 500` und muss separat repariert werden.
|
||||
|
||||
- 2026-06-20: **Live-Nexus nach Deploy-Stoerung verifiziert, Bao-Folgetasks angelegt und Agent-Workflow live gegengeprueft.**
|
||||
- `https://nexus.noveria.net/` lieferte wieder `200 OK` mit SPA-Titel `Nexus | Noveria Operations`.
|
||||
- `/health/live` lieferte `200 Healthy`.
|
||||
- `GET /api/dashboard/tasks/board`, `GET /api/dashboard/tasks/agent-overview` und `GET /api/dashboard/agents` lieferten mit `X-Nexus-Api-Key` wieder `200 OK`.
|
||||
- Neuer Task angelegt: `Restore agent progress visibility in Nexus` (`assignedTo=bao`, `priority=High`, State `Backlog`).
|
||||
- Neuer Task angelegt: `Review: Agenten-Progress mit letztem Status + Timestamp sichtbar machen` (`assignedTo=bao`, State `Backlog`).
|
||||
- Live-Artefakt-Pruefung bestaetigt Frontend-Strings fuer `nur Iris und Bao`, `researcher`, `executor`, `Worauf warte ich?`, `expectedFrom` und `isAgentTask`.
|
||||
- Reversible Live-Verifikation erfolgreich: temp. Agent-Task mit `expectedFrom=researcher` erschien korrekt in `waitingForOthers`, erzeugte Activity und wurde direkt wieder geloescht (`DELETE ... -> 204`).
|
||||
- Reversible Notification-Verifikation erfolgreich: simulierte Bao-Aenderung (`X-Agent-Id: bao`) erzeugte live `task_content_changed` und `task_status_changed` fuer Iris; simulierte Iris-Statusaenderung erzeugte live `task_review` fuer Bao.
|
||||
- Live-Regel fuer Delete bestaetigt: Tasks lassen sich nur in `Backlog` oder `Done` loeschen; ein temp. Review-Task lieferte erwartungsgemaess `403` bis zum Ruecksetzen auf `Backlog`.
|
||||
- Geaenderte Dateien: `nexus.md`, `phases/changelog.md`.
|
||||
|
||||
- 2026-06-20: **Researcher und Executor in den Agent-Task-Workflow aufgenommen.**
|
||||
- `ValidAssignees` in TaskService.cs um `"researcher"` und `"executor"` erweitert.
|
||||
- Frontend `expectedFromLabel`-Mapping, Create-Task- und Detail-Dropdowns um Researcher (🔬) und Executor (⚡) ergänzt.
|
||||
|
||||
+14
-2
@@ -1,6 +1,6 @@
|
||||
# Deployment
|
||||
|
||||
> Letzte Aktualisierung: 2026-06-13
|
||||
> Letzte Aktualisierung: 2026-06-20
|
||||
> Status: ✅ CD v3 (Auto + Manual)
|
||||
> Live-URL: https://nexus.noveria.net
|
||||
|
||||
@@ -175,8 +175,19 @@ Stelle sicher, dass `.env` existiert und alle `***`-Platzhalter ersetzt sind.
|
||||
- [x] Main-Deploys koennen Version-Bump + Git-Tag automatisch setzen; Non-Main-Deploys bleiben read-only (2026-06-13)
|
||||
- [x] Reviewer-Handoff bei Deploy/Rollback-Fehlern (2026-06-13)
|
||||
- [x] Database-Backup-Workflow mit pg_dumpall + Gitea-Artifact (2026-06-13)
|
||||
- [x] Live-Recheck nach Deploy-Stoerung: `/health`, SPA-Root und `GET /api/dashboard/tasks` wieder 200; Bao-Folgetask zur Agent-Progress-Visibility erstellt (2026-06-20)
|
||||
- [x] Agent-Progress-Stand (`2d21885`) manuell als sauberer Commit-Snapshot live ausgerollt, nachdem der normale Gitea-Deploy-Trigger blockierte (2026-06-20)
|
||||
|
||||
## Verifizierung (2026-06-09)
|
||||
## Verifizierung
|
||||
|
||||
### 2026-06-20
|
||||
|
||||
- https://nexus.noveria.net/ → 200 OK, SPA geladen (`<title>Nexus | Noveria Operations</title>`)
|
||||
- /health → 200 Healthy, PostgreSQL + Runtime healthy
|
||||
- /api/dashboard/tasks → 200 OK mit `X-Nexus-Api-Key`
|
||||
- Follow-up-Task `Restore agent progress visibility in Nexus` fuer `assignedTo=bao` erfolgreich angelegt
|
||||
|
||||
### 2026-06-09
|
||||
|
||||
- https://nexus.noveria.net → 200 OK, SPA geladen
|
||||
- /health → Healthy
|
||||
@@ -197,6 +208,7 @@ Stelle sicher, dass `.env` existiert und alle `***`-Platzhalter ersetzt sind.
|
||||
|
||||
## Offene Arbeit
|
||||
|
||||
- [!] Gitea-Deploy-Trigger reparieren: `POST /actions/workflows/deploy.yaml/dispatches` liefert aktuell `HTTP 500`; fuer Commit `2d21885` war deshalb kein erfolgreicher normaler Deploy-Run belegbar
|
||||
- [ ] Docker-Socket-Risiko im CD-Workflow final adressieren (kommt spaeter)
|
||||
- [ ] Docker-Logs und Container-Health-Monitoring einrichten
|
||||
- [ ] Restore-Drill fuer Backup/Recovery einmal realistisch durchspielen und dokumentieren
|
||||
|
||||
Reference in New Issue
Block a user