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

Finalize UI truthfulness and bootstrap hardening

Browse Source
This commit is contained in:
master
2026-04-16 16:23:54 +03:00
parent 4799aa2402
commit bc6b1c5959
145 changed files with 10503 additions and 9837 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
devops/compose/README.md
View File

@@ -290,38 +290,26 @@ docker compose -f docker-compose.integrations.yml ps gitea
Register the default local-ready integration catalog once the stack is up:
```powershell
powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1 `
-Tenant demo-prod
```bash
stella auth login
stella config integrations bootstrap local
```
The helper creates and verifies the 13 turnkey local providers on a fresh
machine. GitLab server/CI and the GitLab registry remain opt-in because they
require Vault-backed PAT material. The scripted local path is:
The CLI creates and verifies the 13 turnkey local providers on a fresh
machine. GitLab server/CI and the GitLab registry remain opt-in but stay inside
the same first-party product flow:
```powershell
powershell -ExecutionPolicy Bypass -File scripts/bootstrap-local-gitlab-secrets.ps1 `
-VerifyRegistry
powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1 `
-Tenant demo-prod `
-IncludeGitLab
powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1 `
-Tenant demo-prod `
-IncludeGitLab `
-IncludeGitLabRegistry
```bash
stella config integrations bootstrap local --include-gitlab
stella config integrations bootstrap local --include-gitlab --include-gitlab-registry
```
Or run the GitLab-backed registration in one step:
```powershell
powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1 `
-Tenant demo-prod `
-IncludeGitLab `
-IncludeGitLabRegistry `
-BootstrapGitLabSecrets
```
The local bootstrap command mints the owned local GitLab PAT against the
compose fixture, stages the resulting `access-token` and `registry-basic`
entries into the writable Vault target, binds the returned `authref://...`
values to the GitLab integrations, and verifies health. The older PowerShell
scripts remain available as compatibility helpers, but they are no longer the
preferred product path for the Stella-owned local fixture lane.
For a repeatable browser-driven proof of the Integrations Hub path itself, run:
@@ -387,15 +375,21 @@ Gitea is now bootstrapped by the compose service itself: a fresh `stellaops-gite
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:
the CLI exposes the owned local fixture path through:
```bash
stella config integrations bootstrap local --include-gitlab
stella config integrations bootstrap local --include-gitlab --include-gitlab-registry
```
For production or customer-managed third-party systems, use the lower-level
Secret Authority commands directly:
```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.
**Backend connector plugins** (8 total, loaded in Integrations service):