changed-only mode: edits to plain-resource files reached only via kustomize resources: refs (outside any KS spec.path) yield an empty keep set

[nberk2]

Version

flate 0.4.10 (container image), also traced against pkg/change/ownership.go on main.

Layout that triggers it

A base/overlay repo where a few meta Flux Kustomizations claim overlay dirs, and overlays pull app bases from OUTSIDE the claimed subtree via plain kustomize resources: refs:

clusters/prod/flux-system/apps.yaml     # Flux KS, spec.path: ./apps/prod
apps/prod/<app>/kustomization.yaml      # resources: [../../base/<app>, ...]
apps/base/<app>/deployment.yaml         # plain resources live here

Symptom

With --path-orig (or --base), an edit that ONLY touches a plain-resource file under apps/base/<app>/ (the most common change in such repos - image bumps, resource limits) is detected by the tree diff but attributed to no owner, so nothing renders and flate diff all emits nothing:

level=DEBUG msg="changed-only mode" ... changed_files=1
level=DEBUG msg="changed-only keep set" size=0 items=[]

Control experiments (all 0.4.10):

• Edit a file INSIDE the claimed overlay (apps/prod/<app>/ingress.yaml): app enters the keep set, and the rendered diff then correctly includes the base-file delta too.
• Edit a Flux CR (HelmRelease) file in the same unclaimed base dir: caught fine - the full chart template delta renders (resource-level attribution by "file it was loaded from" appears to work; it's only plain resources in unclaimed dirs that fall through).

Why (as far as I can tell)

BuildKSClaims/ownershipIndex claims are KS spec.path prefixes + spec.components + components: read from the kustomization at spec.path. Plain resources: references to dirs outside every claim are not part of the claim set, so ownersOf() returns nil for files under them and the filter drops the change.

Since the loader already walks the full kustomize file graph during discovery, would attributing files via the loaded kustomization's actual input file set (rather than path prefixes alone) be feasible? The single-KS-per-app layout never hits this, but the "few meta-KSs + shared bases" layout is fairly common for smaller repos.

Happy to test patches. (Aside: this made our CI diff comments silently empty for exactly the PRs where reviewers wanted them - documented on our side as a known gap for now.)

[buroa]

Confirmed, and thanks for tracing it as far as ownership.go - that lined up exactly.

Ownership attribution is a pure path-prefix index (spec.path + spec.components + on-disk components:); it never consults resources:. Since a resources: ref legitimately escapes the package directory, a plain resource reached only that way - outside every claimed prefix - resolves to no owner, so the producing Kustomization is never seeded into the keep set and nothing renders.

The good news is the attribution you'd want already exists: the self-produce index walks each KS's full render subtree following resources: escapes, it just records only ConfigMaps and emitted-KS files today. Plan: broaden that walk to emit a general file → owning-KS attribution and have the change filter consult it alongside the prefix index, so an owner-less changed file resolves to its producing KS. Regression test for the escape layout included.