cc-ci-orchestrator/cc-ci-plan/IDEAS.md

Deferred ideas / future enhancements (orchestrator-tracked)

Post-DONE or "revisit later" ideas that are intentionally out of scope for the current build (§2 Definition of Done). Not active work — parked here so they aren't lost. The loops may pull an item into the project BACKLOG.md as [idea] if/when it becomes relevant.

• ALT infra-app model: deploy traefik / warm-keycloak / drone the normal Co-op Cloud way, updated outside Nix via abra by maintainers. (operator-flagged 2026-05-29, alternative to the current Phase-2w design — return to later) The current design Nix-reconciles the infra/warm apps: NixOS systemd oneshots run abra to deploy traefik/keycloak/drone, and a nightly nixos-rebuild auto-updates them to latest with a pre-deploy major/manual-migration gate (WC1.2) + post-deploy health-gated rollback (WC1.1). The alternative: treat the CI server like a normal Co-op Cloud host — traefik, the warm keycloak, and drone are plain abra deployments managed by maintainers, deployed once and upgraded by a human via abra app upgrade (using abra's own release-notes / major-bump caution), with no Nix reconciler and no nightly auto-update for them. Nix would provide only the host substrate (OS, docker/swarm, the harness, secrets), not the infra-app lifecycle.

  • Pros: simpler — no reconciler/rollback/nightly machinery; idiomatic Co-op Cloud ops (maintainers manage these exactly like any other coop-cloud app); updates are normal human abra actions; lower cognitive load (no "infra is special / Nix-driven" layer).
  • Cons: the infra apps are no longer reproducible-from-git — a VM recreate (the D8 throwaway rebuild) would NOT re-establish traefik/keycloak/drone; they'd need manual redeploy after a rebuild (D8 then covers only the host + harness, not the infra apps). Loses the automated nightly-latest + health-gated auto-rollback; infra updates + rollback become manual/operator discipline. Drifts from the project's "declarative, rebuildable from scratch" ethos.
  • Note: it's essentially one-or-the-other for the update path — a hybrid where Nix bootstraps them but maintainers also abra app upgrade them creates the dual-ownership conflict (the Nix reconciler would fight/redeploy over the maintainer's version on the next activation).
  • When to revisit: if the reconciler + rollback + nightly machinery proves high-maintenance or brittle, or if maintainers strongly prefer normal coop-cloud workflow over the Nix layer — weigh that against how much we value full reproducibility (D8) + hands-off auto-updates. Added: 2026-05-29.

• Optional --extra-tests flag for heavy / operational tests (opt-in heavy suite). Some recipe tests are "more than needed" for the default CI signal — state-management / long-running-instance / load / helper-script operational tests that don't fit the ephemeral per-run-deploy model cheaply but are useful occasionally. Today they're deferred to cc-ci/machine-docs/DEFERRED.md (e.g. matrix-synapse compress_state.sh, test_complexity_limit.sh, test_purge.sh) and don't run. Idea: add an opt-in --extra-tests flag (e.g. !testme --extra-tests on a PR comment, or a STAGES=extra / EXTRA_TESTS=1 Drone build parameter) that the orchestrator passes through; recipes declare an extra/ test dir or mark tests with @pytest.mark.extra; on opt-in the orchestrator runs them alongside the default tiers (still one deploy, still teardown). Default off so default CI stays fast; the operator can ask for the heavy suite when reviewing a PR that touches an extra-covered area (e.g. matrix-synapse's abra helpers). When implemented, each matching DEFERRED entry can be CLOSED by porting its test into the recipe's extra/ and noting the commit in DEFERRED.md. Why deferred for now: default coverage is sufficient; this is a later breadth/depth knob, not a critical-path feature. Added: 2026-05-28.

• Optional webhook self-registration (admin-access environments). We deliberately made polling the primary trigger and require the CI server/bot to run on read-level access only — so the server does not auto-register Gitea webhooks (that needs repo-admin), and webhook setup is a documented manual admin task (§4.1, docs/enroll-recipe.md). Later, for environments where the CI server does hold admin on the recipe repos (or an org-level admin token is available), consider adding an opt-in, off-by-default feature (e.g. WEBHOOK_AUTOREGISTER=1) that auto-registers and idempotently reconciles the issue_comment webhook (URL, events, HMAC secret) on enrolled repos — matching our declarative-reconcile pattern (§9) — giving low-latency push triggering with zero manual setup. Must stay off by default and fall back to manual-doc + polling when admin isn't available, so the least-privilege (read-only) default is preserved. Why deferred: polling already satisfies D1 and the read-only posture is the goal; this is a convenience optimization for a different deployment profile. Added: 2026-05-27.