From 2f9d7df78f3acea68f06104eb5e9f0bdd2534bd0 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Tue, 2 Jun 2026 00:43:44 +0000 Subject: [PATCH] ideas: package cc-ci itself as a Co-op Cloud recipe (parked, not implementing) Co-Authored-By: Claude Opus 4.8 --- cc-ci-plan/IDEAS.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/cc-ci-plan/IDEAS.md b/cc-ci-plan/IDEAS.md index 4abb2c7..025dcc5 100644 --- a/cc-ci-plan/IDEAS.md +++ b/cc-ci-plan/IDEAS.md @@ -111,3 +111,22 @@ item into the project `BACKLOG.md` as `[idea]` if/when it becomes relevant. - **abra/secret overhead:** avoid regenerating/re-inserting secrets redundantly across stages. *Why deferred:* hardware was the real lever and is fixed; these are speculative software gains best validated by measurement, not assumed. *Added:* 2026-05-30. + +- [ ] **Package cc-ci itself as a Co-op Cloud recipe (deploy it with `abra` like any other app).** + *(operator idea 2026-06-02 — not implementing now)* + Today cc-ci is a NixOS flake that declares the whole server. Idea: split it so the **app layer** + (the `!testme` bridge, dashboard, and runner) ships as a Co-op Cloud **recipe**, on top of a host/ + Swarm provided by NixOS (or any existing Co-op Cloud host). It would then be deployed/upgraded/ + backed-up via `abra` like any recipe — and could **test itself** (deploy `cc-ci`-the-recipe, run its + own lifecycle = ultimate self-regression; pairs with the regression-canary work). + - *Pros:* dogfooding (cc-ci managed by the same tooling it tests); portability/accessibility (any + Co-op Cloud operator could `abra app deploy cc-ci` instead of needing the flake + a dedicated host); + cleaner host-vs-CI-app separation. + - *Cons / crux:* the runner must orchestrate Swarm deploys of recipes-under-test, which a normal + (unprivileged) recipe can't do — needs either a Docker-socket mount (privileged recipe; test stacks + share the host → blast-radius/isolation risk), DinD (heavy/fragile), or **a control-plane recipe + driving a separate disposable test Swarm over SSH** (cleanest, biggest change). Also loses the + "entire server reproducible from one flake" property (host + CI-app become two artifacts). + - *When to revisit:* after the server regression canaries land (want self-tests before re-architecting + the thing that runs them). Treat as a design spike — the runner's Swarm-access model (socket / DinD / + separate Swarm) is the decision that drives everything else.