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

Decommission forge compatibility pointers

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-05 17:33:52 +02:00
parent 1fa503c16d
commit 0ae9bca830
11 changed files with 120 additions and 116 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
Makefile
View File

@@ -1,10 +1,6 @@
SHELL := /usr/bin/env bash SHELL := /usr/bin/env bash
.DEFAULT_GOAL := help .DEFAULT_GOAL := help
GITEA_RELEASE ?= gitea
GITEA_NAMESPACE ?= default
FORGE_REPO ?= /home/worsch/railiance-forge
VERGABE_RELEASE ?= vergabe-teilnahme VERGABE_RELEASE ?= vergabe-teilnahme
VERGABE_NAMESPACE ?= vergabe-teilnahme VERGABE_NAMESPACE ?= vergabe-teilnahme
VERGABE_CHART ?= charts/vergabe-teilnahme VERGABE_CHART ?= charts/vergabe-teilnahme
@@ -18,7 +14,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 ?= $(FORGE_REPO)/helm/gitea-values.sops.yaml SOPS_SENTINEL ?=
DRY_RUN_CREATE_NAMESPACES ?= false DRY_RUN_CREATE_NAMESPACES ?= false
##@ Operator checks ##@ Operator checks
@@ -26,23 +22,12 @@ DRY_RUN_CREATE_NAMESPACES ?= false
check-tools: ## Check required operator tools and warn about optional diagnostics check-tools: ## Check required operator tools and warn about optional diagnostics
tools/check-tools.sh tools/check-tools.sh
check-sops: ## Verify the local SOPS age key can decrypt the configured sentinel check-sops: ## Verify the local SOPS age key can decrypt SOPS_SENTINEL
SOPS_SENTINEL=$(SOPS_SENTINEL) tools/check-sops.sh SOPS_SENTINEL="$(SOPS_SENTINEL)" tools/check-sops.sh
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 compatibility
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: ## 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: ## 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 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 \
kubectl cnpg status apps-pg -n databases; \ kubectl cnpg status apps-pg -n databases; \
@@ -99,4 +84,4 @@ help: ## Show this help
/^[a-zA-Z0-9_-]+:.*?##/ { printf " \033[36m%-20s\033[0m %s\n", $$1, $$2 } \ /^[a-zA-Z0-9_-]+:.*?##/ { printf " \033[36m%-20s\033[0m %s\n", $$1, $$2 } \
/^##@/ { printf "\n\033[1m%s\033[0m\n", substr($$0, 5) }' $(MAKEFILE_LIST) /^##@/ { printf "\n\033[1m%s\033[0m\n", substr($$0, 5) }' $(MAKEFILE_LIST)
.PHONY: check-tools check-sops k8s-server-dry-run gitea-deploy gitea-ingress-deploy gitea-status apps-pg-status vergabe-dry-run vergabe-deploy vergabe-ingress-deploy vergabe-status vergabe-migrate vergabe-seed vergabe-superuser vergabe-logs vergabe-db-url-secret help .PHONY: check-tools check-sops k8s-server-dry-run apps-pg-status vergabe-dry-run vergabe-deploy vergabe-ingress-deploy vergabe-status vergabe-migrate vergabe-seed vergabe-superuser vergabe-logs vergabe-db-url-secret help

42
SCOPE.md
View File

@@ -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 `railiance-forge` - consume forge-owned source and registry capabilities through the
boundary instead of owning forge runtime state in S5. `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 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,15 +55,8 @@ lessons into reusable S5 app release patterns.
## In Scope ## In Scope
- Transitional Gitea compatibility wrappers: - Consumption of forge-owned source and registry capabilities from S5 app
- `make gitea-deploy`; release docs and values, without owning forge runtime configuration.
- `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`;
- canonical operating docs in `/home/worsch/railiance-forge/docs/`.
- `vergabe-teilnahme` as the first concrete S5 application release: - `vergabe-teilnahme` as the first concrete S5 application release:
- chart in `charts/vergabe-teilnahme/`; - chart in `charts/vergabe-teilnahme/`;
- values in `helm/vergabe-teilnahme-values.yaml`; - values in `helm/vergabe-teilnahme-values.yaml`;
@@ -130,11 +123,13 @@ lessons into reusable S5 app release patterns.
## Current State ## Current State
- 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 now live in `railiance-forge`; this repo keeps Helm/SOPS/manifests now live in `railiance-forge`; this repo no longer keeps
transitional Makefile wrappers only. Gitea deploy/status wrappers or registry pointer docs.
- 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 live in `railiance-forge`; S5 runbooks link to those
compatibility pointers. docs directly when app releases consume forge artifacts.
- The final source-of-truth decision for forge ownership is recorded in
`docs/forge-source-of-truth-decision.md`.
- The `issue-core` migration is still blocked on publishing `issue-core==0.2.0` - The `issue-core` migration is still blocked on publishing `issue-core==0.2.0`
with package credentials in the `issue-core` repo and refreshing the with package credentials in the `issue-core` repo and refreshing the
`vergabe-teilnahme` lock in its source repo. `vergabe-teilnahme` lock in its source repo.
@@ -152,8 +147,6 @@ lessons into reusable S5 app release patterns.
## Known Gaps And Opportunities ## Known Gaps And Opportunities
- 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 - 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
@@ -212,8 +205,8 @@ from that file.
source forge, registry, package registry, runner substrate, and artifact source forge, registry, package registry, runner substrate, and artifact
evidence belong to `railiance-forge`; this repo consumes those capabilities. evidence belong to `railiance-forge`; this repo consumes those capabilities.
- Potentially confusing terms: - Potentially confusing terms:
"deployment" here means app release deployment unless a command explicitly "deployment" here means app release deployment. Forge runtime deployment and
delegates to `railiance-forge` for current Gitea operation. registry operation belong to `railiance-forge`.
--- ---
@@ -238,7 +231,7 @@ from that file.
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 app release guardrails 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, registry-consumer, helm, django, vergabe-teilnahme, workload, deployment]
``` ```
```capability ```capability
@@ -256,11 +249,12 @@ keywords: [operator, runbook, sops, cnpg, dry-run, smoke-test, deployment]
2. Read `INTENT.md` for the stable purpose of the S5 layer. 2. Read `INTENT.md` for the stable purpose of the S5 layer.
3. Read this file for scope and boundaries. 3. Read this file for scope and boundaries.
4. Read the active files in `workplans/`. 4. Read the active files in `workplans/`.
5. For Gitea registry work, start with 5. For Gitea registry work, use the forge-owned docs directly:
`/home/worsch/railiance-forge/docs/gitea-container-registry.md` and `/home/worsch/railiance-forge/docs/gitea-container-registry.md` and
`/home/worsch/railiance-forge/docs/gitea-package-registry.md`; the local `/home/worsch/railiance-forge/docs/gitea-package-registry.md`.
files are compatibility pointers.
6. For `vergabe-teilnahme`, start with `docs/vergabe-teilnahme.md`, then inspect 6. For `vergabe-teilnahme`, start with `docs/vergabe-teilnahme.md`, then inspect
`charts/vergabe-teilnahme/`, `helm/vergabe-teilnahme-values.yaml`, and `charts/vergabe-teilnahme/`, `helm/vergabe-teilnahme-values.yaml`, and
`manifests/vergabe-teilnahme-ingress.yaml`. `manifests/vergabe-teilnahme-ingress.yaml`.
7. Run `make check-tools` and `make check-sops` before deploy work. 7. Run `make check-tools` before deploy work. Run
`SOPS_SENTINEL=<encrypted-file> make check-sops` when app release work
touches encrypted SOPS files.

33
docs/forge-source-of-truth-decision.md Normal file
View File

@@ -0,0 +1,33 @@
# Forge Source Of Truth Decision
Date: 2026-06-05
## Decision
`railiance-forge` is the source of truth for current Gitea operation, future
Forgejo migration, forge runtime deployment, source hosting, container and
Python package registries, Actions runner substrate, artifact retention, and
forge operating evidence.
`railiance-apps` consumes those forge capabilities only as release
infrastructure for S5 application workloads. It does not keep Gitea
deploy/status wrappers, forge SOPS sentinels, registry-retention procedures, or
local compatibility copies of forge registry docs.
## Rationale
The forge layer is cross-cutting infrastructure for source control, packages,
images, runners, and promotion evidence. Keeping it in S5 made app release
runbooks responsible for non-app runtime state. The dedicated forge repo gives
operators one place to change forge runtime behavior while allowing S5 app
runbooks to cite forge evidence and consume published artifacts.
## Consequences
- Forge runtime changes start in `/home/worsch/railiance-forge`.
- S5 app release work links to forge docs instead of duplicating registry or
runner operating procedures.
- App-specific charts, values, manifests, smoke tests, and runbooks remain in
`/home/worsch/railiance-apps`.
- Source repos still own application code, package metadata, package publishing,
image build definitions, and lock regeneration.

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

@@ -1,16 +0,0 @@
# Gitea Container Registry
Canonical registry operating guidance now lives in:
```text
/home/worsch/railiance-forge/docs/gitea-container-registry.md
```
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
evidence, storage notes, retention posture, and future Forgejo registry
ownership. Use `railiance-apps` only for S5 app release values and app runbooks
that consume already-published images.

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

@@ -1,16 +0,0 @@
# Gitea Package Registry
Canonical package-registry operating guidance now lives in:
```text
/home/worsch/railiance-forge/docs/gitea-package-registry.md
```
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,
publish/install recipes, retention posture, and future Forgejo package
ownership. Use `railiance-apps` only for S5 app release values and app runbooks
that consume already-published packages.

16
docs/operator-setup.md
View File

@@ -1,10 +1,16 @@
# Operator Setup # Operator Setup
Run these checks before deploying or rotating any S5 workload: Run these checks before deploying any S5 workload:
```bash ```bash
make check-tools make check-tools
make check-sops ```
When the app release work touches encrypted SOPS files, also verify the
operator age identity against the encrypted file being changed:
```bash
SOPS_SENTINEL=<encrypted-file> make check-sops
``` ```
## Required Tools ## Required Tools
@@ -27,7 +33,7 @@ for primary/replica health and backup state.
## SOPS Age Key Bootstrap ## SOPS Age Key Bootstrap
SOPS-encrypted values in this repo expect an age identity at: SOPS-encrypted values used by app release work expect an age identity at:
```text ```text
~/.config/sops/age/keys.txt ~/.config/sops/age/keys.txt
@@ -46,9 +52,9 @@ Bootstrap procedure:
```bash ```bash
chmod 600 ~/.config/sops/age/keys.txt chmod 600 ~/.config/sops/age/keys.txt
``` ```
5. Verify decryption: 5. Verify decryption against the encrypted file being changed:
```bash ```bash
make check-sops SOPS_SENTINEL=<encrypted-file> make check-sops
``` ```
Do not commit age identities, decrypted values, or copied SOPS plaintext Do not commit age identities, decrypted values, or copied SOPS plaintext

8
tools/check-sops.sh
View File

@@ -1,9 +1,15 @@
#!/usr/bin/env bash #!/usr/bin/env bash
set -euo pipefail set -euo pipefail
SOPS_SENTINEL="${SOPS_SENTINEL:-helm/gitea-values.sops.yaml}" SOPS_SENTINEL="${SOPS_SENTINEL:-}"
SOPS_AGE_KEY_FILE="${SOPS_AGE_KEY_FILE:-$HOME/.config/sops/age/keys.txt}" SOPS_AGE_KEY_FILE="${SOPS_AGE_KEY_FILE:-$HOME/.config/sops/age/keys.txt}"
if [[ -z "$SOPS_SENTINEL" ]]; then
echo "ERROR: SOPS_SENTINEL is not set" >&2
echo "Set SOPS_SENTINEL to the encrypted file you want to verify." >&2
exit 1
fi
if ! command -v sops >/dev/null 2>&1; then if ! command -v sops >/dev/null 2>&1; then
echo "ERROR: sops is not installed" >&2 echo "ERROR: sops is not installed" >&2
exit 1 exit 1

30
workplans/RAILIANCE-WP-0005-s5-app-release-readiness.md
View File

@@ -19,9 +19,9 @@ state_hub_workstream_id: "685f1c18-33c0-400d-a2b1-e1dae0f27c3e"
The 2026-06-04 review of `SCOPE.md` against the actual repository The 2026-06-04 review of `SCOPE.md` against the actual repository
implementation found that `railiance-apps` has moved beyond "Gitea Helm values" implementation found that `railiance-apps` has moved beyond "Gitea Helm values"
and now owns the repeatable S5 application release surface: Gitea registry and now owns the repeatable S5 application release surface: forge-backed
enablement, the `vergabe-teilnahme` Helm release, operator guardrails, and artifact consumption, the `vergabe-teilnahme` Helm release, operator
deployment runbooks. guardrails, and deployment runbooks.
The 2026-06-05 `railiance-forge` extraction moved canonical registry operating The 2026-06-05 `railiance-forge` extraction moved canonical registry operating
docs and registry-retention policy into the new forge layer. This workplan now docs and registry-retention policy into the new forge layer. This workplan now
@@ -34,7 +34,7 @@ The same review found several gaps:
tied to the old local `issue-core` build context. tied to the old local `issue-core` build context.
- First-app lessons are documented, but there is no reusable checklist for the - First-app lessons are documented, but there is no reusable checklist for the
next S5 app release. next S5 app release.
- Gitea package storage and app database backup responsibilities need clearer - Forge package storage and app database backup responsibilities need clearer
contracts with platform-layer work. contracts with platform-layer work.
- The server-side dry-run workflow does not state its live-cluster/CRD - The server-side dry-run workflow does not state its live-cluster/CRD
prerequisites clearly enough for a future runner. prerequisites clearly enough for a future runner.
@@ -57,7 +57,7 @@ It should explain:
- why this repo exists as the S5 application deployment surface; - why this repo exists as the S5 application deployment surface;
- what problem it solves for operators and source app repos; - what problem it solves for operators and source app repos;
- what it intentionally does not own across S1-S4 boundaries; - what it intentionally does not own across S1-S4 boundaries;
- how Gitea, package registry enablement, `vergabe-teilnahme`, and future S5 - how forge-owned registry capabilities, `vergabe-teilnahme`, and future S5
apps fit together; apps fit together;
- how workplan files relate to State Hub workstreams and task rows. - how workplan files relate to State Hub workstreams and task rows.
@@ -84,14 +84,15 @@ Focus areas:
- document the package-registry credential path for private Python package - document the package-registry credential path for private Python package
installs without committing tokenized index URLs; installs without committing tokenized index URLs;
- state when `vergabe-teilnahme/uv.lock` must be regenerated in the source repo; - state when `vergabe-teilnahme/uv.lock` must be regenerated in the source repo;
- keep `docs/gitea-package-registry.md` focused on the S5 registry endpoint and - link to forge-owned registry endpoint docs and source-repo release docs
cross-link source-repo release docs instead of duplicating them. instead of duplicating them in S5.
Done when the Railiance operator docs describe the portable image promotion path Done when the Railiance operator docs describe the portable image promotion path
and no active runbook tells an operator to rely on a sibling repo checkout. and no active runbook tells an operator to rely on a sibling repo checkout.
Completed on 2026-06-05 by updating `docs/vergabe-teilnahme.md` and replacing Completed on 2026-06-05 by updating `docs/vergabe-teilnahme.md` and replacing
the local registry docs with compatibility pointers to `railiance-forge`. local registry ownership with direct links to `railiance-forge`. The temporary
compatibility pointers were removed later by `RAILIANCE-WP-0006-T10`.
--- ---
@@ -178,7 +179,7 @@ PR checks or still needs runner/cluster preparation.
--- ---
## T06 - Define Gitea package registry storage and retention posture ## T06 - Hand off Gitea package registry storage and retention posture
```task ```task
id: RAILIANCE-WP-0005-T06 id: RAILIANCE-WP-0005-T06
@@ -187,8 +188,8 @@ priority: medium
state_hub_task_id: "382ba252-0f54-45fa-8e33-e656f4472341" state_hub_task_id: "382ba252-0f54-45fa-8e33-e656f4472341"
``` ```
Document the operating posture for Gitea package storage while Gitea remains the Document the forge-owned operating posture for Gitea package storage while
active forge. Gitea remains the active forge.
Include: Include:
@@ -199,9 +200,8 @@ Include:
- handoff to platform backup/restore work when package data becomes production - handoff to platform backup/restore work when package data becomes production
critical. critical.
Done when registry growth is no longer only a note in Done when registry growth is no longer only a note in S5 app docs.
`docs/gitea-container-registry.md`.
Completed on 2026-06-05 by moving the canonical storage and retention posture Completed on 2026-06-05 by moving the canonical storage and retention posture
to `/home/worsch/railiance-forge/docs/initial-operating-contracts.md`; the local to `/home/worsch/railiance-forge/docs/initial-operating-contracts.md`; S5 app
registry docs are compatibility pointers. runbooks now cite forge docs directly.

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

@@ -4,7 +4,7 @@ type: workplan
title: "Extract railiance-forge and formalize forge-layer contracts" title: "Extract railiance-forge and formalize forge-layer contracts"
domain: railiance domain: railiance
repo: railiance-apps repo: railiance-apps
status: active status: finished
owner: codex owner: codex
topic_slug: railiance topic_slug: railiance
planning_priority: high planning_priority: high
@@ -158,8 +158,9 @@ compatibility pointers left in `railiance-apps`. Deploy-capable Gitea
Helm/SOPS/manifests and Makefile deploy/status targets also moved to Helm/SOPS/manifests and Makefile deploy/status targets also moved to
`railiance-forge` after the review 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 `railiance-apps` temporarily kept compatibility wrappers until
decryption, or Kubernetes apply was run. `RAILIANCE-WP-0006-T10`. No live deploy, SOPS decryption, or Kubernetes apply
was run.
--- ---
@@ -196,7 +197,7 @@ 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.
Completed 2026-06-05: `railiance-apps/SCOPE.md` now treats forge as an upstream Completed 2026-06-05: `railiance-apps/SCOPE.md` now treats forge as an upstream
service and keeps only compatibility wrappers for moved Gitea operations. service and keeps app release ownership separate from moved Gitea operations.
`railiance-enablement/SCOPE.md` and `railiance-enablement/INTENT.md` now `railiance-enablement/SCOPE.md` and `railiance-enablement/INTENT.md` now
separate reusable S4 workflow templates and paved paths from forge-owned separate reusable S4 workflow templates and paved paths from forge-owned
runtime, registries, runner substrate, labels, credentials, and artifact runtime, registries, runner substrate, labels, credentials, and artifact
@@ -385,7 +386,7 @@ cycle. Validation passed with `0 error(s), 0 warning(s)`.
```task ```task
id: RAILIANCE-WP-0006-T10 id: RAILIANCE-WP-0006-T10
status: todo status: done
priority: medium priority: medium
state_hub_task_id: "5bca2a11-453c-4cd0-b86a-7ed269564dfb" state_hub_task_id: "5bca2a11-453c-4cd0-b86a-7ed269564dfb"
``` ```
@@ -404,3 +405,10 @@ Steps:
Done when no active railiance workplan asks operators to modify forge runtime Done when no active railiance workplan asks operators to modify forge runtime
state from the wrong repo. state from the wrong repo.
Completed 2026-06-05: removed the app-side Gitea deploy/status compatibility
wrappers, deleted local registry pointer docs, changed `make check-sops` to
require an explicit `SOPS_SENTINEL`, refreshed active workplans so package
registry and token ownership point to `railiance-forge` and source repos,
archived `RAIL-AP-WP-0001`, and recorded the final source-of-truth decision in
`docs/forge-source-of-truth-decision.md` and State Hub.

4
workplans/archived/260605-RAIL-AP-WP-0001-gitea-container-registry.md
View File

@@ -4,11 +4,11 @@ type: workplan
title: "Enable Gitea Container Registry for Cluster Image Publishing" title: "Enable Gitea Container Registry for Cluster Image Publishing"
domain: railiance domain: railiance
repo: railiance-apps repo: railiance-apps
status: finished status: archived
owner: railiance owner: railiance
topic_slug: railiance topic_slug: railiance
created: "2026-05-15" created: "2026-05-15"
updated: "2026-05-19" updated: "2026-06-05"
planning_priority: high planning_priority: high
planning_order: 1 planning_order: 1
state_hub_workstream_id: "abd268e6-5af9-45ec-93e0-5ffca0211dd0" state_hub_workstream_id: "abd268e6-5af9-45ec-93e0-5ffca0211dd0"

30
workplans/railiance-apps-WP-0004-app-deployment-improvements.md
View File

@@ -9,7 +9,7 @@ owner: railiance
topic_slug: railiance topic_slug: railiance
planning_priority: medium planning_priority: medium
created: "2026-05-19" created: "2026-05-19"
updated: "2026-05-23" updated: "2026-06-05"
state_hub_workstream_id: "b61a9aca-4e43-4b3d-a48b-999e0fa842cf" state_hub_workstream_id: "b61a9aca-4e43-4b3d-a48b-999e0fa842cf"
--- ---
@@ -20,7 +20,7 @@ This workplan collects concrete follow-ups surfaced while shipping
independent, and can be picked up in isolation when the next S5 app independent, and can be picked up in isolation when the next S5 app
lands or when the next operator onboards. Activated on 2026-05-22; lands or when the next operator onboards. Activated on 2026-05-22;
local railiance-apps guardrails are implemented, with the package local railiance-apps guardrails are implemented, with the package
publication item blocked on Gitea package publish credentials. publication item blocked on forge-owned Gitea package publish credentials.
## I01 — URL-encode DB passwords at Secret-build time ## I01 — URL-encode DB passwords at Secret-build time
@@ -102,15 +102,17 @@ proper wheel with version, and switch the dep to
`issue-core>=0.2,<0.3` with a normal index URL. The Dockerfile then `issue-core>=0.2,<0.3` with a normal index URL. The Dockerfile then
drops the `--build-context` and the build becomes portable. drops the `--build-context` and the build becomes portable.
**Coordination:** depends on Gitea PyPI enablement in `railiance-apps` **Coordination:** depends on the forge-owned Gitea PyPI endpoint and package
(small Helm values change) and a release pipeline for `issue-core` token posture in `railiance-forge`, plus a release pipeline for `issue-core`
(separate repo). in its source repo.
**Local progress 2026-05-22.** `helm/gitea-registry-values.yaml` now **Local progress 2026-05-22.** `helm/gitea-registry-values.yaml` set
sets `packages.LIMIT_SIZE_PYPI: -1`, and `packages.LIMIT_SIZE_PYPI: -1` while Gitea was still operated from this repo.
`docs/gitea-package-registry.md` documents the Gitea PyPI endpoint plus That registry operating surface has since moved to `railiance-forge`; current
the `issue-core` migration. The remaining release and dependency change PyPI endpoint docs live at
must happen in the `issue-core` and `vergabe-teilnahme` repos. `/home/worsch/railiance-forge/docs/gitea-package-registry.md`. The remaining
release and dependency change must happen in the `issue-core` and
`vergabe-teilnahme` repos.
**Cross-repo progress 2026-05-23.** `issue-core` now has a validated **Cross-repo progress 2026-05-23.** `issue-core` now has a validated
`make package-check` build and Gitea Actions publish workflow for the `make package-check` build and Gitea Actions publish workflow for the
@@ -171,8 +173,9 @@ decrypt a known sentinel would catch this at the first deploy attempt
rather than at the failing apply. rather than at the failing apply.
**Implemented 2026-05-22.** Added `docs/operator-setup.md`, **Implemented 2026-05-22.** Added `docs/operator-setup.md`,
`tools/check-sops.sh`, and `make check-sops` using `tools/check-sops.sh`, and `make check-sops`. After the forge extraction,
`helm/gitea-values.sops.yaml` as the sentinel by default. `make check-sops` requires an explicit `SOPS_SENTINEL=<encrypted-file>` so this
repo does not depend on forge-owned Gitea SOPS files.
--- ---
@@ -239,7 +242,8 @@ wraps the pattern.
## Notes ## Notes
- Items were activated on 2026-05-22. Local railiance-apps pieces are - Items were activated on 2026-05-22. Local railiance-apps pieces are
complete except I03, which is blocked on Gitea package publish credentials. complete except I03, which is blocked on forge-owned Gitea package publish
credentials and source-repo release work.
- I06 is genuinely cross-repo; the others are local to - I06 is genuinely cross-repo; the others are local to
`railiance-apps` or its operator workflow. `railiance-apps` or its operator workflow.
- The first three items (I01, I02, I03) are the highest-leverage - The first three items (I01, I02, I03) are the highest-leverage