# Kustomize generatorOptions

> generatorOptions tunes ConfigMap and Secret generators: disable the hash suffix, add labels and annotations. Reference for the fields and CI rollout effects.

Source: https://latchkey.dev/learn/command-reference/kustomize-generator-options  
Updated: 2026-06-30

generatorOptions applies shared settings, such as disabling the name hash, to every ConfigMap and Secret generator.

When you want all generated ConfigMaps and Secrets to skip the hash suffix or share labels, generatorOptions sets it once instead of per generator.

## What it does

generatorOptions sets defaults for all generators in the kustomization: disableNameSuffixHash turns off the content hash on every generated name, while labels and annotations attach metadata to every generated ConfigMap and Secret. A per-generator options block overrides these globals.

## Common usage

```kustomization.yaml
generatorOptions:
  disableNameSuffixHash: true
  labels:
    generated-by: kustomize
  annotations:
    note: shared-generator-options

configMapGenerator:
  - name: app-config
    literals:
      - LOG_LEVEL=info
```

## Fields

| Field | What it does |
| --- | --- |
| disableNameSuffixHash | Skip the content hash suffix on generated names |
| labels | Labels added to every generated resource |
| annotations | Annotations added to every generated resource |
| immutable | Mark generated ConfigMaps/Secrets immutable |

## In CI

Disabling the hash trades automatic rollouts for stable names. If you set disableNameSuffixHash: true, you must trigger rollouts yourself (for example kubectl rollout restart) when config changes, since the Deployment spec no longer changes. Keep the hash on unless an external consumer needs a fixed name.

## Common errors in CI

Config changes that do not roll out are the classic symptom of disableNameSuffixHash: true; the ConfigMap updates in place but pods keep the old mounted copy until restarted. With immutable: true, any later edit to the data fails apply with "field is immutable" because immutable ConfigMaps cannot be updated; delete and recreate instead.

## 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.

```Terminal
# 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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### Kustomize generatorOptions?

When you want all generated ConfigMaps and Secrets to skip the hash suffix or share labels, generatorOptions sets it once instead of per generator.

### What it does?

generatorOptions sets defaults for all generators in the kustomization: disableNameSuffixHash turns off the content hash on every generated name, while labels and annotations attach metadata to every generated ConfigMap and Secret. A per-generator options block overrides these globals.

### In CI?

Disabling the hash trades automatic rollouts for stable names. If you set disableNameSuffixHash: true, you must trigger rollouts yourself (for example kubectl rollout restart) when config changes, since the Deployment spec no longer changes. Keep the hash on unless an external consumer needs a fixed name.

### Common errors in CI?

Config changes that do not roll out are the classic symptom of disableNameSuffixHash: true; the ConfigMap updates in place but pods keep the old mounted copy until restarted. With immutable: true, any later edit to the data fails apply with "field is immutable" because immutable ConfigMaps cannot be updated; delete and recreate instead.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt