kustomize build: Render an Overlay in CI
kustomize build <dir> assembles the resources, transformers, and generators of an overlay into plain YAML on stdout.
build is the workhorse: point it at an overlay directory and it prints the exact manifests a cluster would receive. In CI you capture that output as a reviewable artifact.
What it does
kustomize build reads the kustomization.yaml in the target directory, recursively accumulates referenced resources and bases, applies every transformer and generator, and writes the combined manifests to stdout. It does not contact a cluster; it is pure rendering.
Common usage
kustomize build overlays/prod
kustomize build overlays/prod -o rendered.yaml
# render then apply the exact bytes
kustomize build overlays/prod | kubectl apply -f -Flags
| Flag | What it does |
|---|---|
| -o, --output <path> | Write to a file or directory instead of stdout |
| --enable-helm | Allow helmCharts inflation |
| --load-restrictor <mode> | Control reading files outside the directory |
| --enable-alpha-plugins | Permit alpha exec/container plugins |
| --reorder <mode> | Order resources (legacy or none) |
In CI
Render to an artifact and diff it against the previous render so reviewers see the exact change, then apply that file rather than re-rendering at apply time. Pin the kustomize version on the runner: transformer defaults and output ordering have changed between versions and can silently alter rendered YAML.
Common errors in CI
"Error: unable to find one of 'kustomization.yaml', 'kustomization.yml' or 'Kustomization' in directory" means you pointed build at a directory without that file. "accumulating resources" errors point at a missing or invalid referenced file. "must specify --enable-helm" means a helmCharts entry without the flag. A non-zero exit with no manifests usually means a transformer error upstream; read the first error line.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes