the-custodian/workplans/CUST-WP-0059-forgejo-ci-publish-cutover-tail.md

id	type	title	domain	status	owner	topic_slug	planning_priority	planning_order	created	updated	state_hub_workstream_id
CUST-WP-0059	workplan	Forgejo CI/publish cutover — retire residual gitea workflows	infotech	active	codex	custodian	medium	59	2026-07-16	2026-07-16	98d88a93-52d5-4bcb-9be3-6345e1b21785

Forgejo CI/publish cutover — retire residual gitea workflows

Origin

Follow-up from fixing the state-hub deployment pulling from gitea.coulomb.social (2026-07-16). Investigation showed state-hub CI already publishes to Forgejo (.forgejo/workflows/image.yaml → forgejo.coulomb.social/coulomb/state-hub:latest

• :main-<sha>; ran today → main-df19c46). The real residual was two repos whose CI still targeted gitea, plus a deployment-tag misalignment.

Gitea is frozen/read-only (package push disabled per RAIL-HO-WP-0005 T11), so these gitea workflows no longer run — meaning kaizen-agentic effectively had no working CI/publish until this cutover.

Scope

• issue-core: had a redundant .gitea/workflows/publish-python-package.yml (a working .forgejo equivalent already existed) → retired.
• kaizen-agentic: had gitea ci.yml (black/flake8/pytest) + gitea publish, but only a routing-probe .forgejo/ci-smoke.yaml → added real Forgejo ci.yml + publish-python-package.yml, retired the gitea ones.
• state-hub: deployment pinned a stale gitea-era tag (f2e042a) that Forgejo CI never produces (main-<sha>/latest) — running deploy fixed manually 2026-07-16; chart/promotion convention alignment tracked here.

Out of scope: container-image build repos already on Forgejo (state-hub image.yaml, vergabe-teilnahme, reuse-surface, etc.); gitea server decommission (kept as cold fallback until 2026-08-07 per RAIL-HO-WP-0005 T12).

Task: Retire issue-core redundant gitea publish workflow

id: CUST-WP-0059-T01
status: done
priority: medium
state_hub_task_id: "b141add8-6719-4b22-b8f3-70ad3a8e67b1"

git rm issue-core/.gitea/workflows/publish-python-package.yml — the Forgejo publish-python-package.yml (twine → /api/packages/coulomb/pypi) already exists and is authoritative. Done 2026-07-16.

Task: Add kaizen-agentic Forgejo publish workflow

id: CUST-WP-0059-T02
status: done
priority: high
state_hub_task_id: "ee16febb-be92-4319-808f-91f6e209a6ac"

Added kaizen-agentic/.forgejo/workflows/publish-python-package.yml, modeled on issue-core's working Forgejo publish (archive fetch, python -m build, twine upload to forgejo.coulomb.social/api/packages/coulomb/pypi, secrets FORGEJO_PYPI_USER/FORGEJO_PYPI_TOKEN, runs-on: ubuntu-latest). Done.

Task: Add kaizen-agentic Forgejo test CI workflow

id: CUST-WP-0059-T03
status: done
priority: high
state_hub_task_id: "da6a8330-04fc-4535-bc61-397a4fd00551"

Added kaizen-agentic/.forgejo/workflows/ci.yml preserving the retired gitea ci.yml coverage (black/flake8/pytest via archive fetch on ubuntu-latest). Replaces the routing-only ci-smoke.yaml for actual test coverage. Done.

Task: Retire kaizen-agentic gitea workflows

id: CUST-WP-0059-T04
status: done
priority: medium
state_hub_task_id: "0a7bb294-13f5-4892-91c3-ea12ff9cc231"

git rm kaizen-agentic/.gitea/workflows/ci.yml and .gitea/workflows/publish-python-package.yml (replaced by the Forgejo workflows above). Done 2026-07-16.

Task: Verify Forgejo CI + publish actually run

id: CUST-WP-0059-T05
status: todo
priority: high
needs_human: true
state_hub_task_id: "4a97eadb-7102-4658-b567-cc730e3ffaea"

De-risked 2026-07-16: the Forgejo PyPI publish path is proven working — issue-core resolves at /api/packages/coulomb/pypi/simple/issue-core/ (200), and ubuntu-latest is a registered Forgejo runner label. kaizen uses the identical pattern + org secrets, so its publish is high-confidence; it just needs its next v* tag to fire (kaizen simple index is 404 — nothing published since cutover). Remaining confirmation: one green kaizen ci run + one tagged publish.

Confirm the new Forgejo workflows run end-to-end: (1) FORGEJO_PYPI_USER / FORGEJO_PYPI_TOKEN secrets are present (repo or org scope) on issue-core and kaizen-agentic; (2) the ubuntu-latest runner label resolves on Forgejo Actions; (3) a v* tag publishes to the Forgejo PyPI registry; (4) kaizen ci.yml passes (archive fetch + pip install -e .[dev] + black/flake8/pytest work on the runner — note the runner may lack git, hence archive fetch, and full-SHA archive URLs can hang per the state-hub image.yaml note). Fix runner label / secret gaps as found.

Done when: a tagged kaizen-agentic release publishes to Forgejo PyPI and its Forgejo ci run is green.

Task: Align state-hub deployment tag with Forgejo CI output

id: CUST-WP-0059-T06
status: done
priority: medium
state_hub_task_id: "7e75e9be-435d-4a8a-b5c5-340fe7e43772"

Done 2026-07-16: promote-flow documented at state-hub/deploy/railiance/apps/charts/state-hub/PROMOTE.md — CI publishes main-<sha>+latest to Forgejo; promotions pin an immutable main-<sha> via helm upgrade --set image.tag=… --atomic and bump chart appVersion. The chart already defaults image.repository to Forgejo; the one-off f2e042a copy is recorded, with the next promotion directed to move onto a main-<sha>.

The state-hub Helm chart appVersion and the deployed release pin f2e042a (gitea-era; manually copied to Forgejo on 2026-07-16 to fix the live pull). Forgejo CI produces main-<sha> + latest. Align the deployment/promotion convention to reference a Forgejo CI tag (pin a main-<sha> per promotion; update chart appVersion), and document the promote flow so future builds are tracked without manual image copies. Avoid a blind bump to latest/newest main-<sha> — that is a code upgrade past f2e042a and must be tested, not a registry fix.

Done when: state-hub's chart/release references a Forgejo CI-produced tag and the promote flow is documented.