Automate the genesis seed build (auditable Forgejo workflow, not a hand-committed blob) #14
Labels
No labels
bug
discussion
duplicate
enhancement
goal
help wanted
horizon:backlog
horizon:governance
horizon:mvp
invalid
operator-decision
question
roadmap
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
open-platform/mitosis#14
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
genesis/seed.tar.gzis a hand-rebuilt binary blob committed into mitosis. When any component repo (gitops, mcp, agents,_app-template, ci-builder, hello) changes, the seed must be manually regenerated and recommitted — so a fresh clone of the (public) mitosis repo silently lags behind the actual platform. This is the "fragile / ambiguous workflow" friction: cloning +nix run .#updoes not necessarily give you the latest validated platform.Note: the seed is safe to publish — its sealed secrets are ciphertext under the genesis age key (which nobody else holds) and germinate regenerates every secret fresh for each daughter. So public mitosis + bundled seed is fine; the only issue is the manual rebuild.
Proposal — a Forgejo Actions workflow that rebuilds the seed
Add a workflow (on
plat/mitosis, dispatchable + optionally triggered by component-repo changes) that runsbin/seedagainst the platform repos and commits the refreshedgenesis/seed.tar.gz— automated, auditable, visible in the Actions log, no manual blob.Design questions to settle:
workflow_dispatchto start (operator cuts a seed), later a scheduled or component-push trigger.bin/seedclones repos from a Forgejo URL and captures the gitops version pins; ensure it captures the intended (merged-to-main) versions and a clean genesis identity, not a daughter fork.main, or open a PR for human review before it ships to cloners (preferred — keeps the "I QA before publish" loop).Alternative considered
Vendoring component sources into mitosis and building the seed from in-repo sources at germination — more transparent (no binary blob at all), but a larger restructure of the self-hosting model (the components are also live Forgejo repos the platform develops). The workflow approach is the lower-risk first step.
Outcome
Cloning public mitosis +
nix run .#upalways germinates the latest validated platform, with the seed cut by an auditable workflow instead of by hand.Partial progress this session: the bundled
genesis/seed.tar.gzwas MANUALLY re-seeded to carry the full secrets stack (mcp 0.23.15 + secrets-cli + agents 0.7.3 + sync-env + gitops pins) — captured in PR #20. Verified the bundle carries it. The AUTOMATION this issue asks for (a Forgejo workflow that rebuilds the seed on component change) is still TODO. CAVEAT: a full cold germination from the refreshed seed hit the runner flake in #19 — validate a clean germination before relying on the seed / merging #20.PR #20 (manual seed refresh) validated + merged: a germination from it on a clean host comes up healthy with the CURRENT stack (mcp 0.23.15 / agents 0.7.3, full self-serve-secrets + #16 surface), #19 did not reproduce.
mainnow germinates a client-grade platform. The seed-STRUCTURE note for #14 automation: current components live on tags AHEAD of each bundle branch HEAD (deployment is driven by OCI tags pinned in gitops, not branch HEAD) — the automated builder must capture those tags.Seed refresh + coordinated agents 0.7.4 release merged (agents#7 + gitops#5 pins + mitosis#56 seed). Proven on a fresh vxrail germination wb-rob2: the keyscan retry auto-recovered the SSH host-key race (attempt 1 fail → attempt 2 pinned), and a real crew-built app (clockface + CNPG db) shipped FIRST-TRY to a running ----prod pod (builder+reviewer exitCode=0), no manual known_hosts fix, no dev-env 403 block. main now germinates a robust build-and-ship platform.
Loop closed and proven end-to-end: dispatch → reseed workflow built + verified the seed on the runner (run 25, verify table in the PR) → opened PR #81 itself → coldstart gate germinated a fresh platform FROM that seed (13/13) → merged. The genesis seed now refreshes with two layers of machine proof and zero manual blob handling. Three workflow-authoring defects were found and fixed along the way (YAML block-scalar escape, bare jq off the host PATH, set-e vs &&-guard) — all logic now lives in testable scripts (reseed-run.sh / reseed-verify.sh), workflows are thin shims, and every run tees to ~/ci-gate-logs on the runner.
Steady-state note after the no-op guard (PR #84) went live: the guard blocks the true-redundancy race (identical refs — the PR #83 case) but reseed-eligibility is NOT a fixed point by design — mitosis main moves with every tooling merge and gitops moves with prod app activity, so a deliberate dispatch after real changes always produces a meaningful PR (run 29 → PR #85 correctly carries four tooling merges incl. the reseed workflow itself into the seed). Semantic per-repo comparison (filtered-tree for mitosis, platform-subtree for gitops) would make dispatches idempotent but adds real complexity to a manually-dispatched workflow — deliberately NOT built. Dispatch when it matters; the guard catches doubles.