continuous-integration/drone/push Build is failing
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
34 lines
1.6 KiB
Nix
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.
|
|
'';
|
|
};
|
|
};
|
|
}
|