stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity

docs: UI-driven local setup sprints + module dossier sync

Browse Source 
Add SPRINT_20260413_004 (platform UI-only setup bootstrap closure)
with BOOTSTRAP-001..006 delivery tracker, and update sprint 003 and
sprint 20260410-001 execution logs to reflect the completed
persistence / orchestrator / secret-authority work.

Sync module dossiers and operator guides with the new reality: setup
wizard UX, platform-service architecture, CLI setup guide, integrations
architecture + local services, release-orchestrator architecture,
install guide, and compose README.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
master
2026-04-14 07:56:45 +03:00
parent 286c1f758a
commit 398d0659eb
12 changed files with 648 additions and 262 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
devops/compose/README.md
View File

@@ -152,7 +152,7 @@ flows, Rekor, and static/platform bootstrap assets).
The local route table also carries a small set of explicit precedence rules that must stay ahead of the
generic `^/api/v1/{service}` and `^/api/v2/{service}` matchers. Platform-owned surfaces such as
`/api/v1/aoc/*`, `/api/v1/administration/*`, and the aggregated v2 read models
`/api/v1/aoc/*`, `/api/v1/administration/*`, `/api/v1/stella-assistant/*`, and the aggregated v2 read models
`/api/v2/context/*`, `/api/v2/releases/*`, `/api/v2/security/*`, `/api/v2/topology/*`,
`/api/v2/evidence/*`, and `/api/v2/integrations/*` resolve directly to `platform`. Browser
compatibility prefixes such as `/doctor/*` and `/scheduler/*` are segment-bound before they strip the
@@ -316,6 +316,23 @@ powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1
-BootstrapGitLabSecrets
```
For a repeatable browser-driven proof of the Integrations Hub path itself, run:
```powershell
node src/Web/StellaOps.Web/scripts/live-integrations-ui-bootstrap.mjs
```
It signs in to `https://stella-ops.local`, drives the live
`/setup/integrations/onboarding/*` routes through Playwright, and writes
evidence to
`src/Web/StellaOps.Web/output/playwright/live-integrations-ui-bootstrap.json`.
The harness now supports inline GitLab secret staging through the browser when
`STELLAOPS_UI_BOOTSTRAP_GITLAB_ACCESS_TOKEN` and
`STELLAOPS_UI_BOOTSTRAP_GITLAB_REGISTRY_BASIC` are supplied. The separate
first-run setup wizard now reaches the Platform setup API through the
frontdoor and uses persisted installation-scoped setup sessions for the five
truthful control-plane steps.
**Hosts file entries** (add to `C:\Windows\System32\drivers\etc\hosts`):
```
127.1.2.1 gitea.stella-ops.local
@@ -357,6 +374,16 @@ vault kv put secret/nexus admin-password="your-password"
Gitea is now bootstrapped by the compose service itself: a fresh `stellaops-gitea-data` volume creates the default local admin user and the repository root before the container reports healthy. Personal access tokens remain a manual step because Gitea only reveals the token value when it is created.
For UI/CLI-first onboarding, the Integrations Secret Authority API can now
stage GitLab-class credentials and return the generated `authref://...`
bindings without a manual Vault write. The browser flow uses this inline, and
the CLI exposes the same path through:
```bash
stella config integrations secrets targets
stella config integrations secrets upsert-bundle --bundle gitlab-server --target <vault-integration-id> --path gitlab/server --entry access-token=glpat-...
```
For GitLab, `scripts/bootstrap-local-gitlab-secrets.ps1` is the preferred local bootstrap path. It reuses a valid `secret/gitlab` secret when possible and otherwise rotates the local `stella-local-integration` PAT, then writes `authref://vault/gitlab#access-token` plus `authref://vault/gitlab#registry-basic` into the dev Vault. When you enable the optional GitLab registry surface (`GITLAB_ENABLE_REGISTRY=true`), register it through the `GitLabContainerRegistry` provider with `authref://vault/gitlab#registry-basic`. The local Docker registry connector now follows the registry's Bearer challenge and exchanges that `username:personal-access-token` secret against `jwt/auth` before retrying catalog and tag probes.
`docker-compose.testing.yml` is a separate infrastructure-test lane. It starts `postgres-test`, `valkey-test`, mocks, and an isolated Gitea profile on different ports; it does not start Consul or GitLab. Use `docker-compose.integrations.yml` only when you need real third-party providers for connector validation.