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, works out what
it really contains, and proposes one rename MR per directory that also
fixes every reference to the old names.
<kind>_<identifier>.yaml.metadata.names inside, and the kustomization.yaml files that reference them.The naming review runs once a week. For each configured repository it lists every YAML file and parses what is actually inside: the kind, the name and the namespace of each document.
In apps/shop/orders-api/ it finds three files whose
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 batches files that share an
identifier, so a Deployment and its autoscaler are analysed in the
same context and a fix can touch both.
autoscale.yaml shares nothing with app.yaml,
so today they are looked at apart.
The model sees the parsed summary of every file in the directory
and returns a list of from → to pairs, each with a
confidence. Low-confidence suggestions are dropped.
It also flags files sitting in a flat root that belong in a subdirectory, and resources of one application named inconsistently. None of this is applied yet: every suggestion now has to pass deterministic checks.
Each token of a proposed name has to be explained by the file it
renames: a word from its current name, a Kubernetes kind, or a word
from a metadata.name inside it. A token borrowed from a
neighbouring file is rejected.
The kind prefix must match the file's actual kind too. A CloudNativePG
Cluster is not a statefulset_, however
familiar that word is.
kustomization.yaml are left alone: Flux 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. Suggestions in the same directory that make the same kind of change are grouped into a single proposal, so the directory is uniform the moment it merges.
kustomize build is not a rename.
Every kustomization.yaml that names the old file is
rewritten in the same diff. Afterwards the result is parsed again
across every reference field kustomize knows (resources, patches,
generators and more) to prove the old name is gone.
If a reference has a shape the rewriter cannot edit safely, such as
a flow-style list or a generator's files: entry, the
proposal is held as NEEDS_REVIEW with high risk, naming the
exact reference to rewire by hand.
The MR moves files and edits references, nothing else. Merge it and 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 old name cannot be rewritten safely, so that rename ships as NEEDS_REVIEW, risk high, with 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, and 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, the Deployment, Service and autoscaler are analysed together by later scans, and a reader can 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 borrowed from another file.shop kustomization with no object created, changed or deleted.kustomize build apps/shop/orders-api output identical to before.Pure renames plus a matching kustomization edit. Checked the directory for other references to the old names (none). LGTM.
The model suggests names. Deterministic checks decide which renames are allowed out.
<kind>_<identifier> table