app.yaml to a name that says what is inside.
Every repository grows a directory where one file is called
app.yaml, another svc.yaml and a third
autoscale.yaml. Nobody can tell what they hold without
opening them. Once a week the assistant reads each file and works out what
it really contains. Then it proposes one rename draft merge request (MR) per directory.
The MR also fixes every reference to the old names.
<kind>_<identifier>.yaml.metadata.names inside each file. It also reads the kustomization.yaml files (Kustomize files that list resources) that reference them.The naming review runs once a week. For each configured repository it lists every YAML file. Then it parses what is actually inside each file. It reads the kind, the name and the namespace of each document.
In apps/shop/orders-api/ it finds three files. Their
names say nothing about their content.
The convention is <kind>_<identifier>[-qualifier].yaml,
for example deployment_orders-api.yaml. It is not just
tidiness. The repository scanner groups files that share an
identifier, so it analyses a Deployment and its autoscaler in the
same context. A fix can then change both.
autoscale.yaml shares nothing with app.yaml,
so the scanner looks at them apart.
The AI model (LLM) sees the parsed summary of every file in the directory.
It returns a list of from → to pairs. Each pair has a
confidence. The assistant drops low-confidence suggestions.
It also flags files in a flat root that belong in a subdirectory. It flags resources of one application that have inconsistent names. The assistant applies none of these flags yet. Every rename suggestion must pass rule-based checks (checks in code, with no AI model).
The file itself must explain each token of a proposed name. A token can be a word from its current name,
a Kubernetes kind, or a word
from a metadata.name inside it. The assistant rejects a token borrowed from a
neighbouring file.
The kind prefix must also match the file's actual kind. A CloudNativePG
Cluster is not a statefulset_, however
familiar that word is.
kustomization.yaml alone. Flux (the tool that applies git to the cluster) reads every file there anyway, so a rename is pure churn.Merging renames one file at a time leaves a directory half in the old style and half in the new. So the assistant groups suggestions in the same directory that make the same kind of change into a single proposal. The directory is uniform the moment the MR merges.
kustomize build is not a rename.
The assistant rewrites every kustomization.yaml that names the old file
in the same diff. Afterwards it parses the result again
across every reference field that kustomize knows (resources, patches,
generators and more). This proves that the old name is gone.
Sometimes a reference has a shape that the rewriter cannot edit safely, such as
a flow-style list or a generator's files: entry. Then the assistant
holds the proposal as NEEDS_REVIEW with high risk. It names the
exact reference that you must rewire by hand.
The MR moves files and edits references. It does nothing else. After you merge it, Flux applies exactly the same objects as before. The full MR is below.
{ "renames": [
{ "from": "apps/shop/orders-api/app.yaml",
"to": "apps/shop/orders-api/deployment_orders-api.yaml" },
{ "from": "…/svc.yaml", "to": "…/service_orders-api.yaml" },
{ "from": "…/autoscale.yaml", "to": "…/hpa_orders-api.yaml" }
], "confidence": 0.9 }
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - - app.yaml - - svc.yaml - - autoscale.yaml + - deployment_orders-api.yaml + - service_orders-api.yaml + - hpa_orders-api.yaml - servicemonitor_orders-api.yaml
configMapGenerator.files: [nginx.conf, settings.yaml] is flow-style. The assistant cannot rewrite the old name safely, so that rename ships as NEEDS_REVIEW, risk high. It names the line to fix by hand.rename app.yaml → deployment_orders-api.yaml rename svc.yaml → service_orders-api.yaml rename autoscale.yaml → hpa_orders-api.yaml edit kustomization.yaml +3 −3
Illustrative. File names, the repository and the MR number are fictional. The shape of the proposal is the real one.
gitops-ai/naming-orders-api-7a2e into main · 4 files · 3 renamed · +3 −3Three files in apps/shop/orders-api/ do not follow the repository's <kind>_<identifier>.yaml convention. This MR renames them together so the directory is consistent. It also updates the kustomization that lists them.
| Current name | Contains | New name |
|---|---|---|
app.yaml | Deployment orders-api | deployment_orders-api.yaml |
svc.yaml | Service orders-api | service_orders-api.yaml |
autoscale.yaml | HorizontalPodAutoscaler orders-api | hpa_orders-api.yaml |
With a shared identifier, later scans analyse the Deployment, Service and autoscaler together. A reader can also tell what each file holds from the directory listing.
File contents. The rendered objects are identical before and after this MR.
renamed: apps/shop/orders-api/app.yaml → apps/shop/orders-api/deployment_orders-api.yaml renamed: apps/shop/orders-api/svc.yaml → apps/shop/orders-api/service_orders-api.yaml renamed: apps/shop/orders-api/autoscale.yaml → apps/shop/orders-api/hpa_orders-api.yaml apps/shop/orders-api/kustomization.yaml resources: - - app.yaml - - svc.yaml - - autoscale.yaml + - deployment_orders-api.yaml + - service_orders-api.yaml + - hpa_orders-api.yaml - servicemonitor_orders-api.yaml
metadata.name). No token comes from another file.shop kustomization with no object created, changed or deleted.kustomize build apps/shop/orders-api gives the same output as before.Pure renames plus a matching kustomization edit. Checked the directory for other references to the old names (none). LGTM.
The AI model suggests names. Rule-based checks decide which renames the assistant may send out.
<kind>_<identifier> table