The whole server (every service module, the harness tooling, sops wiring, acme-dns) becomes one reusable module, nix/modules/default.nix, exported as nixosModules.cc-ci-server, so another flake can run cc-ci on a host it defines. First consumer: the cc-ci-orchestrator repo's #cc-ci host, which runs the CI server and the orchestrator together on one Hetzner machine (recipe-maintainers/cc-ci-orchestrator branch feat/combined-cc-ci-host).
Two hard-coded values become options (nix/modules/options.nix):
cc-ci.publicIPv4 — acme-dns's listen address and the ns-acme glue record.
cc-ci.sopsFile — the secrets.yaml path; defaults to the secrets/ submodule, but a consumer that imports cc-ci as a plain input (no private submodule) points it at the deployed --recursive checkout and sops-nix reads it at activation (validateSopsFiles off for that case).
The standalone host (nix/hosts/cc-ci-hetzner) now only carries hardware, networking and identity and gets the module via the flake.
Verification:nixosConfigurations.cc-ci evaluates to the byte-identical system derivation on main and on this branch: /nix/store/ckp1244bz86fz3qbx81n5kx60c1lak3m-nixos-system-nixos-26.05.20260803.531670d.drv. No deploy needed for the old host.
The whole server (every service module, the harness tooling, sops wiring, acme-dns) becomes one reusable module, `nix/modules/default.nix`, exported as `nixosModules.cc-ci-server`, so another flake can run cc-ci on a host it defines. First consumer: the cc-ci-orchestrator repo's `#cc-ci` host, which runs the CI server and the orchestrator together on one Hetzner machine (recipe-maintainers/cc-ci-orchestrator branch `feat/combined-cc-ci-host`).
Two hard-coded values become options (`nix/modules/options.nix`):
- `cc-ci.publicIPv4` — acme-dns's listen address and the `ns-acme` glue record.
- `cc-ci.sopsFile` — the secrets.yaml path; defaults to the `secrets/` submodule, but a consumer that imports cc-ci as a plain input (no private submodule) points it at the deployed `--recursive` checkout and sops-nix reads it at activation (`validateSopsFiles` off for that case).
The standalone host (`nix/hosts/cc-ci-hetzner`) now only carries hardware, networking and identity and gets the module via the flake.
**Verification:** `nixosConfigurations.cc-ci` evaluates to the byte-identical system derivation on `main` and on this branch: `/nix/store/ckp1244bz86fz3qbx81n5kx60c1lak3m-nixos-system-nixos-26.05.20260803.531670d.drv`. No deploy needed for the old host.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01FqkQq3CDmFWcQ7u1LzoyRz
The whole server (every service module, the harness tooling, sops wiring,
acme-dns) becomes one reusable module, nix/modules/default.nix, so another
flake can run cc-ci on a host it defines. First consumer: the
cc-ci-orchestrator repo's `#cc-ci` host, which runs the CI server and the
orchestrator together on one Hetzner machine.
Two things the modules hard-coded become options (nix/modules/options.nix):
- cc-ci.publicIPv4 — acme-dns's listen address and ns-acme glue record.
- cc-ci.sopsFile — the secrets.yaml path; defaults to the secrets/ submodule,
but a consumer that imports cc-ci as a plain input (no private submodule)
points it at the deployed --recursive checkout and sops-nix reads it at
activation (validateSopsFiles off for that case).
The standalone host (nix/hosts/cc-ci-hetzner) now only carries hardware,
networking and identity and imports the module via the flake. Verified: the
`#cc-ci` system derivation is byte-identical before and after
(/nix/store/ckp1244bz86fz3qbx81n5kx60c1lak3m-…531670d.drv on both).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FqkQq3CDmFWcQ7u1LzoyRz
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The whole server (every service module, the harness tooling, sops wiring, acme-dns) becomes one reusable module,
nix/modules/default.nix, exported asnixosModules.cc-ci-server, so another flake can run cc-ci on a host it defines. First consumer: the cc-ci-orchestrator repo's#cc-cihost, which runs the CI server and the orchestrator together on one Hetzner machine (recipe-maintainers/cc-ci-orchestrator branchfeat/combined-cc-ci-host).Two hard-coded values become options (
nix/modules/options.nix):cc-ci.publicIPv4— acme-dns's listen address and thens-acmeglue record.cc-ci.sopsFile— the secrets.yaml path; defaults to thesecrets/submodule, but a consumer that imports cc-ci as a plain input (no private submodule) points it at the deployed--recursivecheckout and sops-nix reads it at activation (validateSopsFilesoff for that case).The standalone host (
nix/hosts/cc-ci-hetzner) now only carries hardware, networking and identity and gets the module via the flake.Verification:
nixosConfigurations.cc-cievaluates to the byte-identical system derivation onmainand on this branch:/nix/store/ckp1244bz86fz3qbx81n5kx60c1lak3m-nixos-system-nixos-26.05.20260803.531670d.drv. No deploy needed for the old host.🤖 Generated with Claude Code
https://claude.ai/code/session_01FqkQq3CDmFWcQ7u1LzoyRz