# 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.
      '';
    };
  };
}