Use ephemeral API key for VPS e2e tests

This commit is contained in:
Agent Zero
2026-03-23 23:54:53 +00:00
parent b001d627e1
commit 1b4fc85ff2
3 changed files with 63 additions and 11 deletions

View File

@@ -83,22 +83,21 @@ Recommended env for VPS-backed runs:
```bash
OPENBRAIN_E2E_REMOTE=true
OPENBRAIN_E2E_BASE_URL=https://ob.ingwaz.work
OPENBRAIN_E2E_API_KEY=your_ci_e2e_key
OPENBRAIN__AUTH__ENABLED=true
```
The CI workflow uses this remote mode after `main` deploys so e2e coverage validates the VPS deployment rather than the local runner host.
The CI workflow uses this remote mode after `main` deploys so e2e coverage validates the VPS deployment rather than the local runner host. It now generates a random per-run e2e key, temporarily appends it to the deployed `OPENBRAIN__AUTH__API_KEYS`, runs the suite, then removes the key and restarts the service.
For live deployments, prefer a dedicated key set rather than reusing one API key everywhere. The server already accepts a comma-separated key list via `OPENBRAIN__AUTH__API_KEYS`, so a practical split is:
For live deployments, keep `OPENBRAIN__AUTH__API_KEYS` for persistent non-test access only. The server accepts a comma-separated key list, so a practical split is:
- `prod_live_key` for normal agent traffic
- `ci_e2e_key` for post-deploy CI verification
- `smoke_test_key` for ad hoc diagnostics
In Gitea Actions, that means:
- repo secret `OPENBRAIN__AUTH__API_KEYS=prod_live_key,ci_e2e_key,smoke_test_key`
- repo secret `OPENBRAIN_E2E_API_KEY=ci_e2e_key`
- repo secret `OPENBRAIN__AUTH__API_KEYS=prod_live_key,smoke_test_key`
If you want prod e2e coverage without leaving a standing CI key on the server, the workflow-generated ephemeral key handles that automatically.
## Agent Zero Developer Prompt