| .. | ||
| _PLAN_B_GITHUB_RUNNER.md | ||
| ACT_RUNNER_SETUP.md | ||
| CODEX_DELEGATION_PROMPT.md | ||
| PUBLISH_WORKFLOW.md | ||
| README.md | ||
| ROADMAP.md | ||
Gitea Actions Runner — Hostinger VM rollout
This folder contains everything needed to set up the canonical CI/CD pipeline for @bytelyst/* package publishing: a self-hosted act_runner on the Hostinger Gitea, paired with a matching runner on the corp Mac local Gitea.
File map
| File | Purpose | Audience |
|---|---|---|
CODEX_DELEGATION_PROMPT.md |
🎯 Start here. The bootstrap prompt to hand to Codex on the Hostinger VM + a one-liner. | Human delegator |
ROADMAP.md |
Master execution tracker. Phased checklist (P0 → P6) Codex updates with commit hashes as it executes. | Codex + human reviewer |
ACT_RUNNER_SETUP.md |
Implementation detail for installing act_runner on Hostinger VM. Referenced from roadmap P1–P3. |
Codex |
PUBLISH_WORKFLOW.md |
The actual publish-packages.yml workflow + propagation strategy. Referenced from roadmap P4–P5. |
Codex |
_PLAN_B_GITHUB_RUNNER.md |
Alternative path (GitHub Actions self-hosted runner). Kept for reference; not used. | Reference only |
One-liner to hand off
Read docs/devops/gitea-runner/CODEX_DELEGATION_PROMPT.md in learning_ai_common_plat, then execute the prompt within. Begin with P0.
Why this lives in its own folder
docs/devops/ is filling up with multi-doc workstreams (Azure setup, KV rotation, single-VM deployment, E2EE, etc.). To prevent future roadmaps and delegation prompts from colliding with each other, each multi-doc workstream gets its own subfolder. Pattern to follow when you start a similar workstream:
docs/devops/<workstream-slug>/
README.md # this file — index
CODEX_DELEGATION_PROMPT.md # paste-to-codex bootstrap
ROADMAP.md # phased checklist with checkboxes + commit hashes
<DETAIL_DOC_1>.md # implementation detail
<DETAIL_DOC_2>.md
_PLAN_B_<alternative>.md # discarded alternatives (underscore prefix = deprioritized)
Architecture summary (1-paragraph)
The same v* git tag pushed to two Gitea instances (corp Mac local + Hostinger) triggers each Gitea's own act_runner to build @bytelyst/* packages inside the same pinned Docker image (node:20-bookworm@sha256:...) from the same lockfile. Deterministic builds → byte-identical tarballs → matching SHA512 integrity → lockfiles portable across both registries. No sync script. No GitHub Organization migration. No third-party billing entanglements. See ROADMAP.md §🎯 Outcome for the invariant.