v0.7.0 — Multiple `ingress {}` blocks per workload, with parse-time conflict detection.

Multiple ingress {} blocks per workload, with parse-time conflict detection.

Changes

• deployment and statefulset blocks now accept any number of ingress {} sub-blocks. Each block becomes its own Kubernetes Ingress resource (and a cert-manager Certificate, when tls = true without an explicit tls_secret). Previously, a second ingress {} block silently overwrote the first.
• Resource naming for ingress blocks: the first block defaults to the workload name (e.g. web), and subsequent blocks are auto-suffixed (web-2, web-3, ...). Set name = "..." to override.
• ingress_defaults now applies to every ingress {} block on every workload — not just the first.
• New parse-time validation rejects two error classes that would otherwise produce broken or conflicting manifests:
  • Two ingresses in the same namespace resolving to the same Ingress resource name (whether by explicit name, auto-suffix collision, or cross-workload conflict).
  • Two ingresses in the same namespace deriving the same cert-manager Certificate secret name (e.g. both TLS, no tls_secret, same first host). The error message points you at tls_secret to BYO and skip Certificate generation, or at changing the first host.
• kdef import now round-trips multiple ingresses against the same backend service as separate ingress {} blocks.

Use cases

• Apex → www redirect via nginx.ingress.kubernetes.io/permanent-redirect annotation alongside the main TLS ingress.
• Splitting hosts onto separate Ingress resources for distinct annotation sets (proxy timeouts, body-size limits) without leaving the deployment block.

Docs

• docs/block-types.md — rewritten ingress section with naming rules and conflict semantics.
• docs/variables.md — clarified ingress_defaults applies per-block.

Compatibility

Backward compatible. Existing configs with a single ingress {} produce identical manifests.