kustomize edit add: Modify kustomization.yaml in CI
kustomize edit add and set let a script add resources or change fields in kustomization.yaml without editing YAML by hand.
In a pipeline you often need to bump an image tag or add a label programmatically. The edit subcommands rewrite kustomization.yaml safely so you do not sed YAML.
What it does
kustomize edit operates on the kustomization.yaml in the current directory. add appends entries (resource, label, annotation, configmap); set replaces values (image, namespace, nameprefix); remove deletes entries; and edit fix migrates deprecated fields to current ones.
Common usage
kustomize edit add resource deployment.yaml
kustomize edit set image myapp=registry.example.com/myapp:$GIT_SHA
kustomize edit set namespace prod-web
kustomize edit fix # migrate deprecated fieldsSubcommands
| Command | What it does |
|---|---|
| edit add resource <file> | Append a file to resources |
| edit set image <name>=<img> | Set or override an image entry |
| edit set namespace <ns> | Set the namespace field |
| edit add label / annotation | Add a common label or annotation |
| edit remove resource <file> | Remove a resource entry |
| edit fix | Migrate deprecated fields to current names |
In CI
The canonical pipeline pattern is cd overlays/prod && kustomize edit set image app=:$GIT_SHA before kustomize build, so the freshly built tag flows into the manifests. Run edit fix in a maintenance job to clear deprecation warnings after upgrading kustomize.
Common errors in CI
"Missing kustomization file" means edit was run in a directory without kustomization.yaml; cd into the overlay first. "must specify ... <name>=<newName>:<newTag>" means malformed set image syntax. edit set image silently adds an entry even if the image is not used, so the tag not applying is usually a name mismatch with the manifest, not an edit failure.
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