coulomb/railiance-forge
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Move Gitea deploy surface into forge

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-05 13:19:10 +02:00
parent 8b9f3b341d
commit 9ce24968cd
13 changed files with 219 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/current-forge-asset-inventory.md
View File

@@ -2,18 +2,20 @@
Date: 2026-06-05
This inventory covers forge-related assets currently visible in
This inventory covers forge-related assets that were originally visible in
`/home/worsch/railiance-apps`. It supports `FORGE-WP-0001-T03` and the
coordinating `RAILIANCE-WP-0006` extraction plan.
No files have been moved yet. This document assigns each candidate asset a
target disposition for the first migration plan.
Canonical docs and deploy-capable Gitea files have now moved into
`railiance-forge`. `railiance-apps` keeps compatibility pointers and wrappers
while app-release ownership remains there.
## Summary
| Disposition | Meaning |
|-------------|---------|
| Move | Canonical file should move to `railiance-forge`. |
| Moved | Canonical file has moved to `railiance-forge`. |
| Copy pointer | Copy canonical content to `railiance-forge`, leave a short pointer in `railiance-apps` temporarily. |
| Leave | Keep in `railiance-apps`; it is S5 app-release surface. |
| Adapt | Keep local behavior, but update references after forge extraction. |
@@ -23,21 +25,21 @@ target disposition for the first migration plan.
| Asset | Current role | Target disposition | Notes |
|-------|--------------|--------------------|-------|
| `helm/gitea-values.sops.yaml` | SOPS-encrypted Gitea Helm values. | Move | Must preserve secret boundary; move without decrypting. |
| `helm/gitea-registry-values.yaml` | Non-secret overlay enabling Gitea package/container registry behavior. | Move | This is forge runtime config, not S5 app config. |
| `manifests/gitea-ingress.yaml` | Registry-facing Gitea ingress for `/v2`. | Move | Forge owns Gitea/registry exposure; cluster ingress primitives remain S2. |
| `releases/gitea/values.yaml` | Legacy/plain Gitea release values reference. | Move or supersede | Likely keep only as historical migration reference if still useful. |
| `Makefile` variables `GITEA_*` | Gitea release/chart/value/ingress defaults. | Move | Recreate in `railiance-forge/Makefile`; remove from S5 after compatibility window. |
| `make gitea-deploy` | Deploy/upgrade current Gitea release. | Move | Should become `railiance-forge` operator target. |
| `make gitea-ingress-deploy` | Apply Gitea registry ingress. | Move | Should become `railiance-forge` operator target. |
| `make gitea-status` | Check Gitea pod/service/ingress and `gitea-db` status. | Move | Keep database status as consumer evidence; S3 still owns DB implementation. |
| `helm/gitea-values.sops.yaml` | SOPS-encrypted Gitea Helm values. | Moved | Now `railiance-forge/helm/gitea-values.sops.yaml`; moved without decrypting. |
| `helm/gitea-registry-values.yaml` | Non-secret overlay enabling Gitea package/container registry behavior. | Moved | Now `railiance-forge/helm/gitea-registry-values.yaml`. |
| `manifests/gitea-ingress.yaml` | Registry-facing Gitea ingress for `/v2`. | Moved | Now `railiance-forge/manifests/gitea-ingress.yaml`; labels left unchanged until next reviewed deploy. |
| `releases/gitea/values.yaml` | Legacy/plain Gitea release values reference. | Moved | Now `railiance-forge/releases/gitea/values.yaml`; review before using as active deploy input. |
| `Makefile` variables `GITEA_*` | Gitea release/chart/value/ingress defaults. | Moved | Forge owns canonical variables; apps keeps only release/name compatibility variables. |
| `make gitea-deploy` | Deploy/upgrade current Gitea release. | Moved | Forge owns target; apps delegates during compatibility window. |
| `make gitea-ingress-deploy` | Apply Gitea registry ingress. | Moved | Forge owns target; apps delegates during compatibility window. |
| `make gitea-status` | Check Gitea pod/service/ingress and `gitea-db` status. | Moved | Forge owns target; apps delegates during compatibility window. |
## Copy With Compatibility Pointer
| Asset | Current role | Target disposition | Notes |
|-------|--------------|--------------------|-------|
| `docs/gitea-container-registry.md` | Canonical operator recipe for container registry host, auth, pull secrets, storage note. | Copy pointer | Copy to `railiance-forge/docs/`; leave S5 pointer for app consumers. |
| `docs/gitea-package-registry.md` | Python package registry publishing/install recipe and `issue-core` handoff. | Copy pointer | Forge owns endpoint/registry posture; app/source repos own package release details. |
| `docs/gitea-container-registry.md` | Canonical operator recipe for container registry host, auth, pull secrets, storage note. | Moved | Forge doc is canonical; app-side file is a compatibility pointer. |
| `docs/gitea-package-registry.md` | Python package registry publishing/install recipe and `issue-core` handoff. | Moved | Forge doc is canonical; app-side file is a compatibility pointer. |
| `workplans/RAIL-AP-WP-0001-gitea-container-registry.md` | Historical implementation evidence for enabling Gitea registry in S5. | Copy pointer or archive | Keep historical record in S5, but create forge follow-up for storage/retention/restore posture. |
| `workplans/RAILIANCE-WP-0006-railiance-forge-extraction.md` | Cross-repo coordination plan. | Leave plus pointer | Remains in `railiance-apps` as extraction coordinator; forge work proceeds in `FORGE-WP-*`. |
@@ -67,7 +69,7 @@ target disposition for the first migration plan.
| `SCOPE.md` | Currently lists Gitea as S5-owned workload. | Adapt | After migration, describe forge as upstream release infrastructure. |
| `INTENT.md` | Mentions Gitea/current forge as S5 workload/learning surface. | Adapt | Keep S5 intent but remove long-term forge ownership language. |
| `AGENTS.md` | Repo identity still says application Helm releases, Gitea, coulomb services. | Adapt | Update after Gitea files move. Also update task status examples to State Hub canon. |
| `Makefile` `SOPS_SENTINEL ?= $(GITEA_VALUES)` | `check-sops` currently validates Gitea SOPS values. | Adapt | Once Gitea values move, choose an S5 sentinel or make the check no-op when no SOPS file exists. |
| `Makefile` `SOPS_SENTINEL` | `check-sops` validates the forge-owned Gitea SOPS sentinel for compatibility. | Adapted | Apps points at `/home/worsch/railiance-forge/helm/gitea-values.sops.yaml`. |
| `tools/check-sops.sh` | Generic SOPS sentinel check. | Leave/adapt | Useful beyond forge, but current default must change after move. |
| `.custodian-brief.md` | Generated State Hub brief. | Generated | Do not edit manually; consistency sync updates it. |
@@ -82,21 +84,20 @@ target disposition for the first migration plan.
## First Safe Move Candidate
The first migration should avoid live service changes and move documentation
before deployment configuration:
The first migration avoided live service changes and moved documentation before
deployment configuration:
1. Copy `docs/gitea-container-registry.md` and
`docs/gitea-package-registry.md` into `railiance-forge/docs/`.
2. Replace the originals in `railiance-apps` with short compatibility pointers.
3. Add a `railiance-forge/Makefile` with read-only/status targets first.
4. Move deploy-capable Gitea targets only after the operator path is reviewed.
5. Keep app-side compatibility wrappers until operators have switched.
This gives operators a new canonical forge home while keeping current S5 app
This gives operators a canonical forge home while keeping current S5 app
runbooks discoverable.
## Remote Creation Note
Creating `coulomb/railiance-forge` on the current Gitea instance is blocked:
the configured `tea` login `coulomb` exists, but the stored token is invalid as
of 2026-06-05. The local repo is initialized and State Hub-registered, but
`origin` should not be added until the remote repository exists.
`coulomb/railiance-forge` now exists and the local repo is pushed to
`gitea-remote:coulomb/railiance-forge.git`.

33
docs/deploy-capable-gitea-move-review.md
View File

@@ -2,8 +2,8 @@
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.
Status: executed as a file ownership move. No live Helm deploy, SOPS
decryption, or Kubernetes apply was run.
## Goal
@@ -15,13 +15,13 @@ breaking operator muscle memory.
| 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. |
| `helm/gitea-values.sops.yaml` | SOPS-encrypted | `railiance-forge/helm/gitea-values.sops.yaml` | Moved without decrypting. |
| `helm/gitea-registry-values.yaml` | Non-secret | `railiance-forge/helm/gitea-registry-values.yaml` | Moved. |
| `manifests/gitea-ingress.yaml` | Non-secret | `railiance-forge/manifests/gitea-ingress.yaml` | Moved without live apply. |
| `releases/gitea/values.yaml` | Plaintext legacy/operator values | `railiance-forge/releases/gitea/values.yaml` | Moved as legacy evidence; review before use as active deploy input. |
| `make gitea-deploy` | Deploy-capable | `railiance-forge/Makefile` | Moved; app-side target delegates. |
| `make gitea-ingress-deploy` | Deploy-capable | `railiance-forge/Makefile` | Moved; app-side target delegates. |
| `make gitea-status` | Read-only | `railiance-forge/Makefile` | Moved; app-side target delegates. |
## Proposed Target Layout
@@ -98,14 +98,15 @@ the transition:
- `make gitea-deploy` and `make gitea-ingress-deploy` should either delegate to
forge or fail with a clear message that deploy ownership has moved.
## Resolved During Move
- `releases/gitea/values.yaml` moved as legacy evidence, not as the preferred
active deploy input.
- `manifests/gitea-ingress.yaml` labels were left unchanged to avoid mixing the
file move with a live-facing manifest semantic change.
- The SOPS sentinel in forge points at `helm/gitea-values.sops.yaml`.
## 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?

17
docs/first-migration-plan.md
View File

@@ -2,14 +2,15 @@
Date: 2026-06-05
Status: Phase 1 is underway. The remote repository exists and is pushed, so the
earlier Gitea API blocker no longer applies.
Status: Phases 1 through 3 are complete as file ownership moves. No live Helm
deploy, SOPS decryption, or Kubernetes apply was run.
This plan starts the extraction of forge ownership from `railiance-apps` into
`railiance-forge` without changing the live Gitea deployment.
The rule for the first migration is simple: move knowledge and read-only
operator entry points before moving deploy-capable configuration.
operator entry points before moving deploy-capable configuration. That sequence
has now been followed.
## Goals
@@ -63,18 +64,18 @@ Initial `railiance-forge/Makefile` targets:
- `check-tools`: minimal local tool check for `kubectl`, `helm`, `sops`, and
optional `tea`.
Do not add `gitea-deploy` in this phase.
`gitea-deploy` was intentionally deferred until Phase 3.
Validation:
- Targets are read-only.
- Targets either succeed or fail with clear missing-tool messages.
- `railiance-apps` still owns deploy-capable Gitea targets during the
transition.
- `railiance-apps` still has compatibility wrappers during the transition.
## Phase 3 - Deploy-Capable Target Review
Move deploy-capable Gitea ownership only after Phase 1 and Phase 2 are reviewed.
This is now complete as a file move.
Candidate moves:
@@ -123,5 +124,5 @@ aligned with `origin/main`.
## Next Recommended Action
Complete Phase 1 documentation canonicalization and Phase 2 read-only operator
targets, then review the deploy-capable Gitea file move separately.
Complete Phase 4 S5 scope cleanup and decide when compatibility wrappers in
`railiance-apps` can be retired.

15
docs/gitea-container-registry.md
View File

@@ -1,8 +1,8 @@
# Gitea Container Registry
This is the canonical Railiance operating note for the current Gitea container
registry. Compatibility pointers remain in `railiance-apps` while deploy-capable
Gitea Helm and manifest files still live there.
registry. Compatibility pointers remain in `railiance-apps`; deploy-capable
Gitea Helm and manifest files now live in this repo.
## Registry Target
@@ -10,12 +10,11 @@ Use `gitea.coulomb.social` as the approved registry host. The `/v2` ingress is
live as of 2026-05-15 and returns the OCI registry authentication challenge over
HTTPS.
Registry-specific Gitea settings are currently carried in
`/home/worsch/railiance-apps/helm/gitea-registry-values.yaml`, a non-secret
overlay applied after the SOPS values file by `make gitea-deploy`. It explicitly
enables packages, permits container and PyPI uploads without an app-level size
cap, clears globally disabled repo units, and moves `ROOT_URL` to the HTTPS
host.
Registry-specific Gitea settings are carried in
`helm/gitea-registry-values.yaml`, a non-secret overlay applied after the SOPS
values file by `make gitea-deploy`. It explicitly enables packages, permits
container and PyPI uploads without an app-level size cap, clears globally
disabled repo units, and moves `ROOT_URL` to the HTTPS host.
Image names should use the Gitea owner and package path:

11
docs/gitea-package-registry.md
View File

@@ -1,13 +1,12 @@
# Gitea Package Registry
This is the canonical Railiance operating note for the current Gitea Python
package registry. Compatibility pointers remain in `railiance-apps` while
deploy-capable Gitea Helm and manifest files still live there.
package registry. Compatibility pointers remain in `railiance-apps`;
deploy-capable Gitea Helm and manifest files now live in this repo.
Gitea package support is enabled by
`/home/worsch/railiance-apps/helm/gitea-registry-values.yaml`. That overlay is
applied after the encrypted base values by `make gitea-deploy` and enables both
container packages and Python packages.
Gitea package support is enabled by `helm/gitea-registry-values.yaml`. That
overlay is applied after the encrypted base values by `make gitea-deploy` and
enables both container packages and Python packages.
## Python Packages