diff --git a/AGENTS.md b/AGENTS.md index a963491..803c9bb 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,7 +2,7 @@ ## Repo Identity -**Purpose:** OAS S5 Workloads & Experience Endpoints — application Helm releases, Gitea, coulomb services +**Purpose:** OAS S5 Workloads & Experience Endpoints — application Helm releases, app runbooks, and deployment guardrails **Domain:** railiance **Repo slug:** railiance-apps diff --git a/INTENT.md b/INTENT.md index 02ae3eb..1e69361 100644 --- a/INTENT.md +++ b/INTENT.md @@ -38,9 +38,9 @@ a new archaeology exercise. > *Where we are going.* To become the **canonical home for Railiance application workload releases** - -the Helm values, Kubernetes manifests, registry enablement, app-level runbooks, -smoke checks, and operator recipes that make user-facing services safe to ship -on top of the platform. +the Helm values, Kubernetes manifests, app-level runbooks, smoke checks, and +operator recipes that make user-facing services safe to ship on top of the +platform. This means: @@ -82,10 +82,10 @@ down and mutate those layers to make an app work. An app release is healthy when probes, status checks, smoke tests, and operator evidence say it is healthy, not merely because manifests applied successfully. -### 6. Current Workload, Future Path +### 6. App Workloads, Forge Consumers -Gitea and early application releases are current S5 workloads and learning -surfaces. Their lessons should leave behind reusable deployment patterns that +Applications consume forge artifacts without owning forge runtime state. Early +application releases should leave behind reusable deployment patterns that survive future forge and app migrations. --- @@ -126,8 +126,8 @@ This layer is expected to evolve toward: * Stronger **image and package promotion** patterns * Clearer **backup, restore, and data ownership handoffs** with S3 * More complete **smoke, migration, rollback, and observability** recipes -* Cleaner separation between **current forge operation** and future forge - migration paths +* Cleaner consumption of **forge-owned artifacts and evidence** from app + release runbooks * Self-evidencing, reviewable **application readiness** before promotion --- diff --git a/Makefile b/Makefile index 87a3a62..8877ace 100644 --- a/Makefile +++ b/Makefile @@ -3,10 +3,7 @@ SHELL := /usr/bin/env bash GITEA_RELEASE ?= gitea GITEA_NAMESPACE ?= default -GITEA_CHART ?= gitea-charts/gitea -GITEA_VALUES ?= helm/gitea-values.sops.yaml -GITEA_REGISTRY_VALUES ?= helm/gitea-registry-values.yaml -GITEA_INGRESS ?= manifests/gitea-ingress.yaml +FORGE_REPO ?= /home/worsch/railiance-forge VERGABE_RELEASE ?= vergabe-teilnahme VERGABE_NAMESPACE ?= vergabe-teilnahme @@ -21,7 +18,7 @@ VERGABE_DB_HOST ?= apps-pg-rw.databases VERGABE_DB_PORT ?= 5432 VERGABE_DB_NAME ?= vergabe_db -SOPS_SENTINEL ?= $(GITEA_VALUES) +SOPS_SENTINEL ?= $(FORGE_REPO)/helm/gitea-values.sops.yaml DRY_RUN_CREATE_NAMESPACES ?= false ##@ Operator checks @@ -35,28 +32,16 @@ check-sops: ## Verify the local SOPS age key can decrypt the configured sentinel k8s-server-dry-run: ## Server-side dry-run rendered Helm and committed manifests DRY_RUN_CREATE_NAMESPACES=$(DRY_RUN_CREATE_NAMESPACES) tools/k8s-server-dry-run.sh -##@ Gitea +##@ Gitea compatibility -gitea-deploy: ## Deploy / upgrade Gitea (S5 workload) - helm upgrade --install $(GITEA_RELEASE) $(GITEA_CHART) \ - -f <(sops -d $(GITEA_VALUES)) \ - -f $(GITEA_REGISTRY_VALUES) \ - --namespace $(GITEA_NAMESPACE) --create-namespace +gitea-deploy: ## Compatibility wrapper; Gitea deploy ownership moved to railiance-forge + $(MAKE) -C $(FORGE_REPO) GITEA_RELEASE=$(GITEA_RELEASE) GITEA_NAMESPACE=$(GITEA_NAMESPACE) gitea-deploy -gitea-ingress-deploy: ## Apply the Gitea OCI registry ingress - kubectl apply -f $(GITEA_INGRESS) +gitea-ingress-deploy: ## Compatibility wrapper; Gitea ingress ownership moved to railiance-forge + $(MAKE) -C $(FORGE_REPO) GITEA_RELEASE=$(GITEA_RELEASE) GITEA_NAMESPACE=$(GITEA_NAMESPACE) gitea-ingress-deploy -gitea-status: ## Check Gitea health - kubectl get pods -n $(GITEA_NAMESPACE) -l app.kubernetes.io/instance=$(GITEA_RELEASE) - kubectl get svc -n $(GITEA_NAMESPACE) $(GITEA_RELEASE) - kubectl get ingress -n $(GITEA_NAMESPACE) $(GITEA_RELEASE) --ignore-not-found - @if kubectl cnpg status gitea-db -n databases >/dev/null 2>&1; then \ - kubectl cnpg status gitea-db -n databases; \ - else \ - echo "kubectl cnpg plugin not available; falling back to cnpg resources"; \ - kubectl get cluster gitea-db -n databases; \ - kubectl get pods -n databases -l cnpg.io/cluster=gitea-db; \ - fi +gitea-status: ## Compatibility wrapper; Gitea status ownership moved to railiance-forge + $(MAKE) -C $(FORGE_REPO) GITEA_RELEASE=$(GITEA_RELEASE) GITEA_NAMESPACE=$(GITEA_NAMESPACE) gitea-status apps-pg-status: ## Check the shared apps-pg cnpg cluster @if kubectl cnpg status apps-pg -n databases >/dev/null 2>&1; then \ diff --git a/SCOPE.md b/SCOPE.md index 32bdbca..b519754 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -10,8 +10,8 @@ Last reviewed: 2026-06-05 ## One-liner S5 Workloads & Experience Endpoints for Railiance: application Helm releases, -Kubernetes workload manifests, transitional Gitea release configuration, and -operator runbooks for user-facing services such as `vergabe-teilnahme`. +Kubernetes workload manifests, app deployment guardrails, and operator runbooks +for user-facing services such as `vergabe-teilnahme`. --- @@ -45,8 +45,8 @@ intent, the current implementation is aligned around: - keep application release concerns in S5 while respecting S1-S4 ownership; - provide enough runbook and guardrail coverage that the next app does not rediscover the same deployment traps; -- consume the current Gitea/registry surface through the emerging - `railiance-forge` boundary while live deploy-capable files are still moving. +- consume the current Gitea/registry surface through the `railiance-forge` + boundary instead of owning forge runtime state in S5. The remaining gap is not the absence of intent; it is turning the first-app lessons into reusable S5 app release patterns. @@ -55,12 +55,11 @@ lessons into reusable S5 app release patterns. ## In Scope -- Gitea as a transitional S5-managed workload until `railiance-forge` completes - the deploy-capable migration: - - Helm release values in `helm/gitea-values.sops.yaml`; - - non-secret registry overlay in `helm/gitea-registry-values.yaml`; - - ingress manifest in `manifests/gitea-ingress.yaml`; - - `make gitea-deploy`, `make gitea-status`, and related operator checks. +- Transitional Gitea compatibility wrappers: + - `make gitea-deploy`; + - `make gitea-ingress-deploy`; + - `make gitea-status`; + - each delegates to `/home/worsch/railiance-forge`. - App-side registry consumption pointers: - `docs/gitea-container-registry.md`; - `docs/gitea-package-registry.md`; @@ -106,7 +105,6 @@ lessons into reusable S5 app release patterns. ## Relevant When -- Deploying or upgrading Gitea as the current S5 forge workload. - Consuming already-published registry artifacts from S5 app releases. - Deploying or upgrading `vergabe-teilnahme` on Railiance. - Adding another user-facing S5 application release. @@ -132,7 +130,8 @@ lessons into reusable S5 app release patterns. ## Current Implementation Surface - Gitea is deployed and operational as the current forge. Its deploy-capable - Helm/SOPS/manifests still live here during the `railiance-forge` extraction. + Helm/SOPS/manifests now live in `railiance-forge`; this repo keeps + transitional Makefile wrappers only. - The Gitea container and Python package registry paths are verified. Canonical registry operating docs now live in `railiance-forge`; app-side files here are compatibility pointers. @@ -153,10 +152,8 @@ lessons into reusable S5 app release patterns. ## Known Gaps And Opportunities -- Deploy-capable Gitea Helm/SOPS/manifests still need to move to - `railiance-forge` after review. -- S5 app docs should continue shedding forge-runtime details and linking to - forge-owned operating contracts. +- S5 app docs should continue shedding residual forge-runtime details and link + to forge-owned operating contracts. - The first-app lessons from `vergabe-teilnahme` are documented, but there is no reusable "new S5 app release checklist" yet. - The manifest dry-run workflow assumes access to a representative cluster and @@ -220,7 +217,7 @@ from that file. ```capability type: infrastructure title: S5 application workload deployment -description: Deploy and operate user-facing Railiance applications as Helm releases and Kubernetes manifests, including transitional Gitea deployment files and the first Django S5 app release. +description: Deploy and operate user-facing Railiance applications as Helm releases and Kubernetes manifests, including app release guardrails and the first Django S5 app release. keywords: [railiance, s5, gitea, registry, helm, django, vergabe-teilnahme, workload, deployment] ``` diff --git a/docs/gitea-container-registry.md b/docs/gitea-container-registry.md index 04d6457..5693a45 100644 --- a/docs/gitea-container-registry.md +++ b/docs/gitea-container-registry.md @@ -6,8 +6,8 @@ Canonical registry operating guidance now lives in: /home/worsch/railiance-forge/docs/gitea-container-registry.md ``` -This compatibility pointer remains in `railiance-apps` while deploy-capable -Gitea Helm, SOPS, and manifest files are still migrating under +This compatibility pointer remains in `railiance-apps` after deploy-capable +Gitea Helm, SOPS, and manifest files moved to `railiance-forge` under `RAILIANCE-WP-0006-T03`. Use `railiance-forge` for registry endpoints, package-token handling, smoke diff --git a/docs/gitea-package-registry.md b/docs/gitea-package-registry.md index d97ac49..abf4a0f 100644 --- a/docs/gitea-package-registry.md +++ b/docs/gitea-package-registry.md @@ -6,8 +6,8 @@ Canonical package-registry operating guidance now lives in: /home/worsch/railiance-forge/docs/gitea-package-registry.md ``` -This compatibility pointer remains in `railiance-apps` while deploy-capable -Gitea Helm, SOPS, and manifest files are still migrating under +This compatibility pointer remains in `railiance-apps` after deploy-capable +Gitea Helm, SOPS, and manifest files moved to `railiance-forge` under `RAILIANCE-WP-0006-T03`. Use `railiance-forge` for the Gitea PyPI endpoint, package-token handling, diff --git a/workplans/RAILIANCE-WP-0006-railiance-forge-extraction.md b/workplans/RAILIANCE-WP-0006-railiance-forge-extraction.md index 35166b7..f7dc636 100644 --- a/workplans/RAILIANCE-WP-0006-railiance-forge-extraction.md +++ b/workplans/RAILIANCE-WP-0006-railiance-forge-extraction.md @@ -123,7 +123,7 @@ indexing and no reliance on `railiance-apps` as its planning home. ```task id: RAILIANCE-WP-0006-T03 -status: in_progress +status: done priority: high state_hub_task_id: "57162f50-d1a4-4fb3-b4fa-503939b22450" ``` @@ -153,11 +153,13 @@ Migration rules: Done when `railiance-apps` no longer owns source-forge deployment config, and current Gitea operation has an equivalent or better home in `railiance-forge`. -Progress 2026-06-05: canonical registry docs moved to `railiance-forge`, with +Completed 2026-06-05: canonical registry docs moved to `railiance-forge`, with compatibility pointers left in `railiance-apps`. Deploy-capable Gitea -Helm/SOPS/manifests and Makefile deploy targets still remain here pending a -separate review. That review is now drafted in +Helm/SOPS/manifests and Makefile deploy/status targets also moved to +`railiance-forge` after the review in `/home/worsch/railiance-forge/docs/deploy-capable-gitea-move-review.md`. +`railiance-apps` now keeps compatibility wrappers only. No live deploy, SOPS +decryption, or Kubernetes apply was run. --- @@ -193,6 +195,10 @@ In `railiance-enablement`: Done when a new operator can answer "is this S4, S5, or forge?" from the scope documents without inspecting historical workplans. +Progress 2026-06-05: `railiance-apps/SCOPE.md` now treats forge as an upstream +service and keeps only compatibility wrappers. `railiance-enablement` still +needs the S4 handoff wording checked after the deploy move. + --- ## T05 - Define artifact lifecycle, retention, and provenance policy