notplantsandClaude Fable 5.1
a8af8429f2
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
26 lines
1.7 KiB
Markdown
26 lines
1.7 KiB
Markdown
---
|
|
name: cc-ci-server-update
|
|
description: (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.lock` in 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-ci` target, which nothing deploys);
|
|
- do not run `nixos-rebuild switch --flake /etc/cc-ci#cc-ci` or `...#cc-ci-hetzner` on 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`.
|