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

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:

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 <target>.

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:

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:

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:

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?

4.0 KiB Raw Blame History