nix/modules/auto-update.nix (own module, no notplants-nix dependency): Tuesday 03:00 UTC, busy-gated (CI run, weekly upgrader, report, sweep, running Drone builds → skip), `nix flake update` → build → switch-to-configuration test → cc-ci health checks (sshd, 0 failed units, core units, every swarm service at replica count, sops decrypted, dashboard/reports/drone 200, opencode UI 401) → profile + bootloader → flake.lock committed and pushed to main → /etc/cc-ci fast-forwarded; revert + lock restore on failure; one-line state file for /cc-ci-status. Skills (.opencode canonical, .claude pointers' descriptions synced): - cc-ci-orchestrator-update: THE host update — drives the auto-update unit by hand; --cc-ci-only for a cc-ci-main-only move; failure playbook. - cc-ci-server-update: delegates to it and explains why the old procedure (rebuilding the cc-ci repo's standalone #cc-ci) must not be run on this host. - cc-ci-update: chains orchestrator-update then tests-update. - cc-ci-status: §5/§6 for one host — auto-update state, generation vs boot generation, front doors (oc.ci = 401), sops, fail2ban, timers, orchestrator agent session, secrets inventory; verdict updated. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FqkQq3CDmFWcQ7u1LzoyRz
1.7 KiB
name, description
| name | description |
|---|---|
| cc-ci-server-update | (Delegates) Update the cc-ci CI server host to the latest nixpkgs — which, since 2026-09-07, is the SAME machine as the orchestrator, built from the cc-ci-orchestrator flake. This skill only forwards to /cc-ci-orchestrator-update; it no longer bumps or rebuilds the cc-ci repo's own flake, because that standalone `#cc-ci` target would replace the combined host config. Invoke as /cc-ci-server-update. |
cc-ci-server-update → /cc-ci-orchestrator-update
There is no separate CI-server host any more. The CI server runs on the cc-ci host
(195.201.88.249) together with the orchestrator, from one flake:
recipe-maintainers/cc-ci-orchestrator #cc-ci, which imports the cc-ci repo's
nixosModules.cc-ci-server and makes that input follow its own nixpkgs and sops-nix.
Run /cc-ci-orchestrator-update. It updates nixpkgs, sops-nix AND the cc-ci input, tests,
health-checks (the CI server's swarm, front doors, sops, acme-dns — the checks this skill used to
do) and switches, via the host's own weekly auto-update unit.
Do not do what the old version of this skill did:
- do not bump
flake.lockin the cc-ci repo expecting it to change the live host (it cannot — the host follows the orchestrator flake's inputs; cc-ci's lock only matters for the standalone#cc-citarget, which nothing deploys); - do not run
nixos-rebuild switch --flake /etc/cc-ci#cc-cior...#cc-ci-hetzneron the host — that is the standalone-server configuration and would take the orchestrator half down.
If what you actually wanted is "the host should run cc-ci main as of now" (a harness or test
change), that is /cc-ci-orchestrator-update --cc-ci-only.