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
**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

16
INTENT.md
View File

@@ -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
---

33
Makefile
View File

@@ -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 \

31
SCOPE.md
View File

@@ -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]
```

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
```
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

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
```
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,

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