diff --git a/docs/deploy-capable-gitea-move-review.md b/docs/deploy-capable-gitea-move-review.md new file mode 100644 index 0000000..8c5a159 --- /dev/null +++ b/docs/deploy-capable-gitea-move-review.md @@ -0,0 +1,111 @@ +# Deploy-Capable Gitea Move Review + +Date: 2026-06-05 + +Status: ready for operator review. No deploy-capable files have been moved by +this review, and no live cluster command is authorized by this document. + +## Goal + +Move current Gitea deployment ownership from `railiance-apps` to +`railiance-forge` without changing live service state, exposing secrets, or +breaking operator muscle memory. + +## Candidate Inventory + +| Current path in `railiance-apps` | Sensitivity | Proposed target | Action | +|---|---:|---|---| +| `helm/gitea-values.sops.yaml` | SOPS-encrypted | `railiance-forge/helm/gitea-values.sops.yaml` | Move after confirming SOPS age access still works from the new repo. Do not decrypt into Git. | +| `helm/gitea-registry-values.yaml` | Non-secret | `railiance-forge/helm/gitea-registry-values.yaml` | Move with the registry docs. | +| `manifests/gitea-ingress.yaml` | Non-secret | `railiance-forge/manifests/gitea-ingress.yaml` | Move and update ownership labels from `railiance-apps` to `railiance-forge` if desired. | +| `releases/gitea/values.yaml` | Plaintext legacy/operator values | `railiance-forge/releases/gitea/values.yaml` or archive | Review before moving; it contains old CoulombCore-era chart notes and a placeholder password comment. | +| `make gitea-deploy` | Deploy-capable | `railiance-forge/Makefile` | Move only after app-side compatibility target is ready. | +| `make gitea-ingress-deploy` | Deploy-capable | `railiance-forge/Makefile` | Move only after app-side compatibility target is ready. | +| `make gitea-status` | Read-only | `railiance-forge/Makefile` | Already introduced as read-only target. | + +## Proposed Target Layout + +```text +railiance-forge/ + helm/ + gitea-values.sops.yaml + gitea-registry-values.yaml + manifests/ + gitea-ingress.yaml + releases/ + gitea/ + values.yaml +``` + +Keep deploy-capable commands in the forge `Makefile`: + +```make +gitea-deploy +gitea-ingress-deploy +gitea-status +``` + +Leave app-side compatibility targets in `railiance-apps` for one transition +window. They should either print the new command location or delegate to +`make -C /home/worsch/railiance-forge `. + +## Review Gates + +- Operator confirms that current Gitea runtime ownership belongs in + `railiance-forge`, not S5. +- `railiance-forge` has the pushed remote and State Hub workplans synced. +- `sops -d helm/gitea-values.sops.yaml` works from the new path for authorized + operators. +- Helm render validation works from the new repo without committing decrypted + values. +- App-side compatibility pointers exist before old commands disappear. +- The move is kept separate from any Forgejo migration or cutover. + +## Validation Plan + +Run these after the files move: + +```bash +git diff --check +make -C /home/worsch/state-hub fix-consistency REPO=railiance-forge +make -C /home/worsch/state-hub fix-consistency REPO=railiance-apps +``` + +Render without writing decrypted secrets into the repo: + +```bash +helm template gitea gitea-charts/gitea \ + --namespace default \ + -f <(sops -d helm/gitea-values.sops.yaml) \ + -f helm/gitea-registry-values.yaml +``` + +Inspect live state without applying changes: + +```bash +make gitea-status +kubectl diff -f manifests/gitea-ingress.yaml --server-side +``` + +## Compatibility Plan + +`railiance-apps` should keep short files or targets at the old locations during +the transition: + +- `docs/gitea-container-registry.md` points to forge docs. +- `docs/gitea-package-registry.md` points to forge docs. +- `make gitea-status` may delegate to forge. +- `make gitea-deploy` and `make gitea-ingress-deploy` should either delegate to + forge or fail with a clear message that deploy ownership has moved. + +## Open Questions + +- Should `releases/gitea/values.yaml` move as an active file or be archived as + legacy evidence? +- Should `manifests/gitea-ingress.yaml` labels change from + `app.kubernetes.io/part-of: railiance-apps` to `railiance-forge` during the + move, or stay stable until the next deploy? +- Should the SOPS sentinel in forge point at `helm/gitea-values.sops.yaml` once + that file moves? +- What restore-drill evidence is required before package data becomes + production-critical? diff --git a/workplans/FORGE-WP-0002-registry-docs-and-readonly-ops.md b/workplans/FORGE-WP-0002-registry-docs-and-readonly-ops.md index 25938bc..3b58eaf 100644 --- a/workplans/FORGE-WP-0002-registry-docs-and-readonly-ops.md +++ b/workplans/FORGE-WP-0002-registry-docs-and-readonly-ops.md @@ -63,7 +63,7 @@ deploy-capable Helm or Kubernetes apply commands. ```task id: FORGE-WP-0002-T03 -status: todo +status: done priority: high state_hub_task_id: "58a8073d-4665-4cf6-a1f8-e4810c7d392d" ``` @@ -80,6 +80,8 @@ Review the next candidate move from `railiance-apps`: Done when the move plan is specific enough to preserve secret boundaries, operator compatibility, and live Gitea stability. +Completed in `docs/deploy-capable-gitea-move-review.md`. + --- ## T04 - Re-home parent workplan references @@ -96,3 +98,20 @@ Update `railiance-apps` docs and workplans so registry operation points to Done when the old app-side registry docs are compatibility pointers instead of competing canonical sources. + +--- + +## T05 - Execute reviewed deploy-capable move + +```task +id: FORGE-WP-0002-T05 +status: todo +priority: high +state_hub_task_id: "6f6fc3a4-a883-4803-84e7-2700629d397a" +``` + +After operator review, move deploy-capable Gitea files and commands into +`railiance-forge` with app-side compatibility targets. + +Done when `railiance-forge` owns Gitea deploy/status/ingress commands and +`railiance-apps` no longer carries live forge deployment files as S5 scope.