Highlights
Lazy loading is now opt-in. v2.3.0 dropped the silent fall-back to an empty REST config and surfaces the underlying clientcmd error directly during terraform plan. That is the right default for mis-typed hosts and malformed certs, but it broke the same-root cluster-plus-manifests pattern (the most common shape being EKS with kubectl manifests in one module), where provider arguments come from outputs of resources that have not been applied yet. Users on those layouts had to pin back to v2.2.0 (see #283).
v2.4.0 adds an optional lazy_load boolean on the provider block, off by default. Setting it to true (or exporting KUBE_LAZY_LOAD=true) restores the pre-v2.3.0 deferred-failure shape: clientcmd errors at provider-configure time are swallowed, an empty REST config is substituted, and the actual client is built lazily on first use. Everyone else keeps the precise diagnostic from v2.3.0.
provider "kubectl" {
host = module.eks.cluster_endpoint
cluster_ca_certificate = base64decode(module.eks.cluster_ca_certificate)
token = data.aws_eks_cluster_auth.this.token
load_config_file = false
lazy_load = true
}Prefer the two-stage apply, data-source-backed credentials, or literal-value smoke test where they fit. Reach for lazy_load = true when the same-root layout is the only one that suits the workflow. The full trade-off and the three alternative workarounds are written up in the Troubleshooting section of the provider docs.
Fixes: #283.
Changelog
- 6a8e563 docs: rebalance new comment lines closer to the 80-char cap
- b2aa47a test(provider): pin apply_retry_count is held per-KubeProvider
- a9ca72d fix(provider): move apply_retry_count from package global onto KubeProvider
- 6029bf3 docs(readme): promote ephemeral resource and bump version constraints
- b055e48 ci(workflows): scope GITHUB_TOKEN to read-only
- 526ed94 ci(workflows): skip CI on documentation-only PRs
- 870f45f feat(provider): add lazy_load to defer kubeconfig errors (#284)
- fe4694c Dependencies: Bump hashicorp/setup-terraform from 3.1.2 to 4.0.1