coulomb/railiance-apps
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Delegate Gitea operations to forge

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-05 13:19:12 +02:00
parent 421c09e902
commit a715be6d28
7 changed files with 46 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
AGENTS.md
View File

@@ -2,7 +2,7 @@
## Repo Identity ## 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 **Domain:** railiance
**Repo slug:** railiance-apps **Repo slug:** railiance-apps

16
INTENT.md
View File

@@ -38,9 +38,9 @@ a new archaeology exercise.
> *Where we are going.* > *Where we are going.*
To become the **canonical home for Railiance application workload releases** - To become the **canonical home for Railiance application workload releases** -
the Helm values, Kubernetes manifests, registry enablement, app-level runbooks, the Helm values, Kubernetes manifests, app-level runbooks, smoke checks, and
smoke checks, and operator recipes that make user-facing services safe to ship operator recipes that make user-facing services safe to ship on top of the
on top of the platform. platform.
This means: 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 An app release is healthy when probes, status checks, smoke tests, and operator
evidence say it is healthy, not merely because manifests applied successfully. 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 Applications consume forge artifacts without owning forge runtime state. Early
surfaces. Their lessons should leave behind reusable deployment patterns that application releases should leave behind reusable deployment patterns that
survive future forge and app migrations. survive future forge and app migrations.
--- ---
@@ -126,8 +126,8 @@ This layer is expected to evolve toward:
* Stronger **image and package promotion** patterns * Stronger **image and package promotion** patterns
* Clearer **backup, restore, and data ownership handoffs** with S3 * Clearer **backup, restore, and data ownership handoffs** with S3
* More complete **smoke, migration, rollback, and observability** recipes * More complete **smoke, migration, rollback, and observability** recipes
* Cleaner separation between **current forge operation** and future forge * Cleaner consumption of **forge-owned artifacts and evidence** from app
migration paths release runbooks
* Self-evidencing, reviewable **application readiness** before promotion * Self-evidencing, reviewable **application readiness** before promotion
--- ---

33
Makefile
View File

@@ -3,10 +3,7 @@ SHELL := /usr/bin/env bash
GITEA_RELEASE ?= gitea GITEA_RELEASE ?= gitea
GITEA_NAMESPACE ?= default GITEA_NAMESPACE ?= default
GITEA_CHART ?= gitea-charts/gitea FORGE_REPO ?= /home/worsch/railiance-forge
GITEA_VALUES ?= helm/gitea-values.sops.yaml
GITEA_REGISTRY_VALUES ?= helm/gitea-registry-values.yaml
GITEA_INGRESS ?= manifests/gitea-ingress.yaml
VERGABE_RELEASE ?= vergabe-teilnahme VERGABE_RELEASE ?= vergabe-teilnahme
VERGABE_NAMESPACE ?= vergabe-teilnahme VERGABE_NAMESPACE ?= vergabe-teilnahme
@@ -21,7 +18,7 @@ VERGABE_DB_HOST ?= apps-pg-rw.databases
VERGABE_DB_PORT ?= 5432 VERGABE_DB_PORT ?= 5432
VERGABE_DB_NAME ?= vergabe_db VERGABE_DB_NAME ?= vergabe_db
SOPS_SENTINEL ?= $(GITEA_VALUES) SOPS_SENTINEL ?= $(FORGE_REPO)/helm/gitea-values.sops.yaml
DRY_RUN_CREATE_NAMESPACES ?= false DRY_RUN_CREATE_NAMESPACES ?= false
##@ Operator checks ##@ 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 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 DRY_RUN_CREATE_NAMESPACES=$(DRY_RUN_CREATE_NAMESPACES) tools/k8s-server-dry-run.sh
##@ Gitea ##@ Gitea compatibility
gitea-deploy: ## Deploy / upgrade Gitea (S5 workload) gitea-deploy: ## Compatibility wrapper; Gitea deploy ownership moved to railiance-forge
helm upgrade --install $(GITEA_RELEASE) $(GITEA_CHART) \ $(MAKE) -C $(FORGE_REPO) GITEA_RELEASE=$(GITEA_RELEASE) GITEA_NAMESPACE=$(GITEA_NAMESPACE) gitea-deploy
-f <(sops -d $(GITEA_VALUES)) \
-f $(GITEA_REGISTRY_VALUES) \
--namespace $(GITEA_NAMESPACE) --create-namespace
gitea-ingress-deploy: ## Apply the Gitea OCI registry ingress gitea-ingress-deploy: ## Compatibility wrapper; Gitea ingress ownership moved to railiance-forge
kubectl apply -f $(GITEA_INGRESS) $(MAKE) -C $(FORGE_REPO) GITEA_RELEASE=$(GITEA_RELEASE) GITEA_NAMESPACE=$(GITEA_NAMESPACE) gitea-ingress-deploy
gitea-status: ## Check Gitea health gitea-status: ## Compatibility wrapper; Gitea status ownership moved to railiance-forge
kubectl get pods -n $(GITEA_NAMESPACE) -l app.kubernetes.io/instance=$(GITEA_RELEASE) $(MAKE) -C $(FORGE_REPO) GITEA_RELEASE=$(GITEA_RELEASE) GITEA_NAMESPACE=$(GITEA_NAMESPACE) gitea-status
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
apps-pg-status: ## Check the shared apps-pg cnpg cluster apps-pg-status: ## Check the shared apps-pg cnpg cluster
@if kubectl cnpg status apps-pg -n databases >/dev/null 2>&1; then \ @if kubectl cnpg status apps-pg -n databases >/dev/null 2>&1; then \

31
SCOPE.md
View File

@@ -10,8 +10,8 @@ Last reviewed: 2026-06-05
## One-liner ## One-liner
S5 Workloads & Experience Endpoints for Railiance: application Helm releases, S5 Workloads & Experience Endpoints for Railiance: application Helm releases,
Kubernetes workload manifests, transitional Gitea release configuration, and Kubernetes workload manifests, app deployment guardrails, and operator runbooks
operator runbooks for user-facing services such as `vergabe-teilnahme`. 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; - keep application release concerns in S5 while respecting S1-S4 ownership;
- provide enough runbook and guardrail coverage that the next app does not - provide enough runbook and guardrail coverage that the next app does not
rediscover the same deployment traps; rediscover the same deployment traps;
- consume the current Gitea/registry surface through the emerging - consume the current Gitea/registry surface through the `railiance-forge`
`railiance-forge` boundary while live deploy-capable files are still moving. boundary instead of owning forge runtime state in S5.
The remaining gap is not the absence of intent; it is turning the first-app The remaining gap is not the absence of intent; it is turning the first-app
lessons into reusable S5 app release patterns. lessons into reusable S5 app release patterns.
@@ -55,12 +55,11 @@ lessons into reusable S5 app release patterns.
## In Scope ## In Scope
- Gitea as a transitional S5-managed workload until `railiance-forge` completes - Transitional Gitea compatibility wrappers:
the deploy-capable migration: - `make gitea-deploy`;
- Helm release values in `helm/gitea-values.sops.yaml`; - `make gitea-ingress-deploy`;
- non-secret registry overlay in `helm/gitea-registry-values.yaml`; - `make gitea-status`;
- ingress manifest in `manifests/gitea-ingress.yaml`; - each delegates to `/home/worsch/railiance-forge`.
- `make gitea-deploy`, `make gitea-status`, and related operator checks.
- App-side registry consumption pointers: - App-side registry consumption pointers:
- `docs/gitea-container-registry.md`; - `docs/gitea-container-registry.md`;
- `docs/gitea-package-registry.md`; - `docs/gitea-package-registry.md`;
@@ -106,7 +105,6 @@ lessons into reusable S5 app release patterns.
## Relevant When ## Relevant When
- Deploying or upgrading Gitea as the current S5 forge workload.
- Consuming already-published registry artifacts from S5 app releases. - Consuming already-published registry artifacts from S5 app releases.
- Deploying or upgrading `vergabe-teilnahme` on Railiance. - Deploying or upgrading `vergabe-teilnahme` on Railiance.
- Adding another user-facing S5 application release. - Adding another user-facing S5 application release.
@@ -132,7 +130,8 @@ lessons into reusable S5 app release patterns.
## Current Implementation Surface ## Current Implementation Surface
- Gitea is deployed and operational as the current forge. Its deploy-capable - 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 - The Gitea container and Python package registry paths are verified. Canonical
registry operating docs now live in `railiance-forge`; app-side files here are registry operating docs now live in `railiance-forge`; app-side files here are
compatibility pointers. compatibility pointers.
@@ -153,10 +152,8 @@ lessons into reusable S5 app release patterns.
## Known Gaps And Opportunities ## Known Gaps And Opportunities
- Deploy-capable Gitea Helm/SOPS/manifests still need to move to - S5 app docs should continue shedding residual forge-runtime details and link
`railiance-forge` after review. to forge-owned operating contracts.
- S5 app docs should continue shedding forge-runtime details and linking to
forge-owned operating contracts.
- The first-app lessons from `vergabe-teilnahme` are documented, but there is - The first-app lessons from `vergabe-teilnahme` are documented, but there is
no reusable "new S5 app release checklist" yet. no reusable "new S5 app release checklist" yet.
- The manifest dry-run workflow assumes access to a representative cluster and - The manifest dry-run workflow assumes access to a representative cluster and
@@ -220,7 +217,7 @@ from that file.
```capability ```capability
type: infrastructure type: infrastructure
title: S5 application workload deployment 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] keywords: [railiance, s5, gitea, registry, helm, django, vergabe-teilnahme, workload, deployment]
``` ```

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

@@ -6,8 +6,8 @@ Canonical registry operating guidance now lives in:
/home/worsch/railiance-forge/docs/gitea-container-registry.md /home/worsch/railiance-forge/docs/gitea-container-registry.md
``` ```
This compatibility pointer remains in `railiance-apps` while deploy-capable This compatibility pointer remains in `railiance-apps` after deploy-capable
Gitea Helm, SOPS, and manifest files are still migrating under Gitea Helm, SOPS, and manifest files moved to `railiance-forge` under
`RAILIANCE-WP-0006-T03`. `RAILIANCE-WP-0006-T03`.
Use `railiance-forge` for registry endpoints, package-token handling, smoke Use `railiance-forge` for registry endpoints, package-token handling, smoke

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

@@ -6,8 +6,8 @@ Canonical package-registry operating guidance now lives in:
/home/worsch/railiance-forge/docs/gitea-package-registry.md /home/worsch/railiance-forge/docs/gitea-package-registry.md
``` ```
This compatibility pointer remains in `railiance-apps` while deploy-capable This compatibility pointer remains in `railiance-apps` after deploy-capable
Gitea Helm, SOPS, and manifest files are still migrating under Gitea Helm, SOPS, and manifest files moved to `railiance-forge` under
`RAILIANCE-WP-0006-T03`. `RAILIANCE-WP-0006-T03`.
Use `railiance-forge` for the Gitea PyPI endpoint, package-token handling, Use `railiance-forge` for the Gitea PyPI endpoint, package-token handling,

14
workplans/RAILIANCE-WP-0006-railiance-forge-extraction.md
View File

@@ -123,7 +123,7 @@ indexing and no reliance on `railiance-apps` as its planning home.
```task ```task
id: RAILIANCE-WP-0006-T03 id: RAILIANCE-WP-0006-T03
status: in_progress status: done
priority: high priority: high
state_hub_task_id: "57162f50-d1a4-4fb3-b4fa-503939b22450" 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 Done when `railiance-apps` no longer owns source-forge deployment config, and
current Gitea operation has an equivalent or better home in `railiance-forge`. 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 compatibility pointers left in `railiance-apps`. Deploy-capable Gitea
Helm/SOPS/manifests and Makefile deploy targets still remain here pending a Helm/SOPS/manifests and Makefile deploy/status targets also moved to
separate review. That review is now drafted in `railiance-forge` after the review in
`/home/worsch/railiance-forge/docs/deploy-capable-gitea-move-review.md`. `/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 Done when a new operator can answer "is this S4, S5, or forge?" from the scope
documents without inspecting historical workplans. 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 ## T05 - Define artifact lifecycle, retention, and provenance policy