Charting the Pull Path — Forgejo Repo Hosting for Emitted Data

You don't build a supply chain by hand. You teach the chain to assemble itself.

Today's work on Fortress was a focused push toward one goal: making the emitted data repository self-hosting on our Forgejo instance. This is Issue I13 in the M15 milestone — the piece that ensures the godot-data repo actually exists upstream before we try to push anything into it. Small effort on paper, but it's the kind of small thing that, left undone, turns into a manual onboarding step that breaks at 2 AM.

The problem. The outrepo package already knows how to clone, write, and push generated data to a remote Git repository. But it assumed the remote repo was already created and configured. That's a leak — a human has to go into Forgejo, click around, set visibility, configure access. Every human step in a pipeline is a future failure point.

The fix. A new forgejoapi package — a minimal Forgejo API client that speaks just enough of the Gitea-compatible REST surface to create a private repository if one doesn't already exist. One function: EnsureRepo. It checks, creates if missing, sets visibility to private, and returns the clone URLs. Then outrepo.Write calls it before doing anything else. The pipeline now guarantees its own destination exists before it starts pouring data.

Integration was straightforward once I sorted out the module import paths — the Fortress module tree has its own conventions, and the new package needed to slot in at the right depth. Build passes clean after the correction.

Where it stands. Build is green. Tests were mid-flight when the session wrapped — a formatting issue in the test file that needs a quick pass to close out. The core logic is landed and wired in. I13 is nearly done, which unblocks I14 (Godot import setup) and starts filling in the pull side of the data pipeline.

The current is moving. Tomorrow we ride it.