feat: add repository projection synchronization
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 1m9s

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a028f0-a42f-7582-89a8-ebaad7343834
This commit is contained in:
tegwick 2026-08-22 16:52:47 +02:00
parent d3258a6ba0
commit 280da08455
7 changed files with 317 additions and 2 deletions

View file

@ -72,3 +72,26 @@ written to a repository. State Hub handoffs:
`T01` remains in progress until those gates are satisfied, the dark workload is
healthy on PostgreSQL, and a restore is verified against the deployed topology.
## Post-preflight status
Later on 2026-08-22, the Forgejo package gate was completed and the package was
registered. A namespace-first apply correction passed five package tests and a
server-side dry-run, then was published as `rapp-sbom-nexus` commit `dd110d1`.
The database owner accepted the declaration under `RAPP-POSTGRES-WP-0005`
(State Hub workplan `d6d36add-27d9-5b5d-b6fe-ce80eb7b6dab`). The distinct
`platform-pg-2` cell and bootstrap secret were created and the cell reached 1/1
Ready. Acceptance remains blocked because:
- Warden still requires the attended founder act for the OpenBao connection,
dynamic runtime/migration roles, exact two-path policy, and renewable parent
token;
- continuous archiving is `False` and the first base backup is
`walArchivingFailing`; the value-safe pod log reports S3 `HeadBucket` 403 for
the governed `platform-pg-2` prefix.
The backup diagnosis and request for a successful base backup plus scratch
restore were sent to `rapp-postgres` as message
`31b72f4b-fcf8-4454-82b7-2dbf325c573e`. The SBOM Nexus workload remains
undeployed and no caller ingress is enabled.

View file

@ -0,0 +1,48 @@
# SBOM-WP-0002-T02 repository projection rehearsal — 2026-08-22
## Result
The projection-only synchronization path is implemented and rehearsed against
an isolated SBOM Nexus database. It does not scan repositories, invoke an
ingest route, or create snapshots.
## Source and selection
The current Repo Manager compatibility projection was read from State Hub's
`GET /repos/` boundary using explicit host id `bnt-lap001`:
| Measure | Result |
| --- | ---: |
| Source repositories | 120 |
| Active | 116 |
| Inactive | 4 |
| Selected checkout path | 120 |
The dry-run used an intentionally unreachable target URL and still completed,
proving that dry-run does not contact or mutate the Nexus target.
## Apply rehearsal
An ephemeral SQLite-backed Nexus on `127.0.0.1:18010` received the projection:
- 120 upserts;
- 120 exact active/path matches on read-back;
- zero missing, mismatched, or extra target repositories;
- zero SBOM ingest calls and zero snapshots.
The bounded catch-up query with `limit=3` returned exactly three of 116 active,
never-attempted repositories, ordered deterministically by slug:
`activity-core`, `adaptive-pricing`, and `agent-harness`. The response reported
`selected_count=3`, `never_count=116`, `stale_count=116`, and
`total_count=116`.
Production apply remains gated on the dark PostgreSQL runtime in
`SBOM-WP-0002-T01`.
## Verification
- `uv run ruff check src tests scripts`: pass
- `uv run pytest -q`: 15 passed, 1 conditional PostgreSQL skip
- projection dry-run: 120 would-upsert, target not contacted
- projection apply/read-back: 120/120 matched
- bounded catch-up: 3/3 selected in deterministic order

View file

@ -52,6 +52,21 @@ operation.
## Import State Hub history
Synchronize the minimum repository identity/path projection first. This command
does not call an ingest endpoint or create an SBOM snapshot:
```bash
uv run python scripts/sync_repository_projections.py \
--source-url http://127.0.0.1:8000 \
--target-url http://127.0.0.1:8010 \
--host-id bnt-lap001 \
--dry-run
```
Remove `--dry-run` only after the target is deployed. The apply path upserts all
active and inactive records, then reads them back and fails on a missing or
mismatched active/path projection. Extra target rows are reported but retained.
Run a read-only preview first:
```bash