Files
cc-ci/nix/modules/options.nix
T
notplantsandClaude Fable 5.1 9b99f81f5f
continuous-integration/drone/push Build is failing
nix: export the CI server as nixosModules.cc-ci-server
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
2026-09-07 19:56:58 +00:00

34 lines
1.6 KiB
Nix

# The few host-identity values the cc-ci modules need but must not hard-code, so that the same
# modules can build the canonical Hetzner host, a throwaway rebuild VM, or a combined host that
# also runs the cc-ci orchestrator (2026-09: recipe-maintainers/cc-ci-orchestrator imports
# `nixosModules.cc-ci-server` from this repo and runs both on one box).
{ lib, ... }:
{
options.cc-ci = {
publicIPv4 = lib.mkOption {
type = lib.types.str;
example = "91.98.47.73";
description = ''
The host's public IPv4 address. acme-dns binds its authoritative listener to it and
publishes it as the `ns-acme` glue record. Must match the Gandi A record for
ns-acme.commoninternet.net and the address the cc-ci DNS names point at.
'';
};
sopsFile = lib.mkOption {
type = lib.types.path;
default = ../../secrets/secrets.yaml;
defaultText = lib.literalExpression "../../secrets/secrets.yaml";
example = "/etc/cc-ci/secrets/secrets.yaml";
description = ''
The sops-encrypted secrets.yaml (recipe-maintainers/cc-ci-secrets). The default is the
`secrets/` git submodule inside this repo, which only exists when this flake is built from
a `--recursive` clone (`git+file:///root/cc-ci?submodules=1`). A consumer that imports
cc-ci as a plain flake input (no submodule) sets this to an absolute path on the host
instead — e.g. the `/etc/cc-ci` deployed checkout's `secrets/secrets.yaml` — which
sops-nix then reads at activation time rather than copying into the store.
'';
};
};
}