feat(kustomize): edit images/replicas overrides through to kustomization.yaml#198
Conversation
…ion.yaml
A live change produced by a kustomization's images:/replicas: entry is now
written back to that entry instead of into the source manifest ("the edit
lands where the value lives"):
- the analyzer parses images:/replicas: entries and attaches an unambiguous
override chain per document, walking true render roots (a referenced base
composes with its parent instead of counting as its own root); distinct
chains from multiple roots attach nothing and emit an
ambiguous-kustomize-overrides diagnostic
- a projection inverts the transformer chain per component (image name / tag
/ digest, replica count), routes each divergence to its supplier (entry or
source file), and verifies by re-simulating the render; anything unsafe
falls back to today's write-through
- manifestedit gains a bounded, comment-preserving kustomization editor that
only updates existing fields on existing entries, all-or-nothing
- patchExisting runs the projection (covering live events and resync), and
/scale field patches route a governed spec.replicas to the entry
- live state equal to the overlay's render is now a true no-op: the source
file's shadowed tag is no longer overwritten on every event/resync
- malformed images:/replicas: values now refuse the folder (they would fail
kustomize build; we can no longer vouch for the render)
Adds docs/design/gitops-api/ (workstream tracker + F1 design, including the
shared-entry divergent-consumers limitation), corpus fixtures pinning the
supported/ambiguous boundary, and tests across all three layers.
Validation: task lint (0 issues), task test (coverage 73.9% -> 74.4%,
baseline raised), task test-e2e (53 passed, 0 failed, 8 skipped).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 28 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (15)
📝 WalkthroughWalkthroughThis PR implements Kustomize ChangesF1 Override Edit-Through
Estimated code review effort: 4 (Complex) | ~75 minutes Sequence Diagram(s)sequenceDiagram
participant Event
participant PlanFlush as plan_flush.go
participant Projection as SplitDesiredForOverrides
participant Kustomization as PatchKustomization
participant SourceFile as Source Manifest
Event->>PlanFlush: live drift (image tag / replicas)
PlanFlush->>Projection: gitRaw, desired, override chain
Projection->>Projection: invert image/replica overrides
Projection-->>PlanFlush: projected desired + override edits
alt override edits present
PlanFlush->>Kustomization: apply scalar edits to entry
Kustomization-->>PlanFlush: patched kustomization bytes
else no override match
PlanFlush->>SourceFile: write-through patch
end
PlanFlush-->>Event: flush result (source and/or kustomization updated)
Estimated code review effort: 4 (Complex) | ~75 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/design/gitops-api/README.md`:
- Around line 45-48: The status for F1 in the design index is out of sync with
the linked `f1-images-replicas-edit-through.md` doc. Update the README table
entry for the F1 feature so its status matches the design doc’s implemented
state, keeping the existing feature name and link intact. Use the F1 row in the
GitOps API README to locate and correct the status text.
In `@internal/manifestanalyzer/overrides.go`:
- Around line 216-261: The shared-base traversal in kustomizeOverrideAssignments
is using a per-root visited set that incorrectly suppresses alternate paths in a
diamond-shaped kustomization graph, so only the first override chain is
recorded. Update the walk logic so recordOverrideChain can see every distinct
path to a resource within the same render root, rather than pruning by directory
alone; use the existing kustomizeOverrideAssignments, walk, and
recordOverrideChain flow to locate the fix. If supporting multiple paths is
intentionally out of scope, add a clear comment or documentation stating that
same-root shared subtrees are not checked for ambiguous overrides.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 66a8a832-f358-405b-9fcd-e5127be28b3c
📒 Files selected for processing (24)
.coverage-baselinedocs/architecture.mddocs/design/gitops-api/README.mddocs/design/gitops-api/f1-images-replicas-edit-through.mdinternal/git/inplace_overrides_test.gointernal/git/manifestedit/kustomization.gointernal/git/manifestedit/kustomization_test.gointernal/git/manifestedit/split.gointernal/git/plan_flush.gointernal/manifestanalyzer/acceptance.gointernal/manifestanalyzer/overrides.gointernal/manifestanalyzer/overrides_projection.gointernal/manifestanalyzer/overrides_projection_test.gointernal/manifestanalyzer/overrides_test.gointernal/manifestanalyzer/store.gointernal/manifestanalyzer/testdata/contextual-namespace/README.mdinternal/manifestanalyzer/testdata/contextual-namespace/supported/images-overlay/deployment.yamlinternal/manifestanalyzer/testdata/contextual-namespace/supported/images-overlay/kustomization.yamlinternal/manifestanalyzer/testdata/contextual-namespace/supported/replicas-overlay/base/deployment.yamlinternal/manifestanalyzer/testdata/contextual-namespace/supported/replicas-overlay/base/kustomization.yamlinternal/manifestanalyzer/testdata/contextual-namespace/supported/replicas-overlay/kustomization.yamlinternal/manifestanalyzer/testdata/contextual-namespace/unsupported/ambiguous-images/kustomization.yamlinternal/manifestanalyzer/testdata/contextual-namespace/unsupported/ambiguous-images/other/kustomization.yamlinternal/manifestanalyzer/testdata/contextual-namespace/unsupported/ambiguous-images/shared.yaml
…backs Review follow-ups for #198: - override-chain cycle protection moves from a per-walk visited set to on-path tracking, so a diamond (one render root reaching a shared base through two overlays) records both chains and trips the ambiguous-kustomize-overrides refusal instead of silently attributing the first path (CodeRabbit major); adds the diamond-images corpus fixture - the write batch logs store-build diagnostics (warning+) once per batch as "manifest store diagnostic", so ambiguity/scope fallbacks the writer takes silently leave a trace in the live path, not just the analyzer CLI - targeted tests for behavior that was only implicitly covered: DocumentBody, digest routing, applyOverrideEdits refusal paths, and two resync integration tests (governed folder in sync -> zero churn; governed drift -> routed to the entry) - docs: gitops-api README marks F1 implemented (CodeRabbit minor), the F1 doc describes the diamond-safe walk and corrects the diagnostic-visibility phrasing, and configuration.md gains a user-facing "Kustomize support in the target path" section (supported subset / loud refusals / silent fallbacks and where to see them) Validation: task lint (0 issues), task test (coverage 74.4% -> 74.5%, baseline raised), task test-e2e (53 passed, 0 failed, 8 skipped). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Description
First rung of the gitops-api workstream (
docs/design/gitops-api/): a live change produced by a kustomization'simages:/replicas:override entry is now written back to that entry, never through into the source manifest — the edit lands where the value lives.Previously these fields were "benign-accepted" but not understood: with an overlay pinning
newTag, every event/resync wrote the rendered tag into the source file, turning the override into dead text and landing deliberate tag bumps in the wrong place. Seedocs/design/gitops-api/f1-images-replicas-edit-through.mdfor the full design.How it works:
internal/manifestanalyzer/overrides.go): parsesimages:/replicas:entries; walks true render roots (a referenced base composes with its parent, innermost-first; every distinct path within a root is recorded, so diamonds trip the ambiguity refusal); attaches an unambiguous override chain per document.overrides_projection.go): inverts the chain per component (image name/tag/digest, replica count), routes each divergence to its supplier (entry vs source file), verifies by re-simulating the render; anything unsafe falls back to today's write-through — never a guess.manifestedit/kustomization.go): bounded, comment-preserving; only updates existing fields on existing entries; all-or-nothing.plan_flush.go):patchExistingruns the projection (covers live events and resync);/scalefield patches route governedspec.replicasto the entry; store-build diagnostics are logged once per write batch so silent fallbacks leave a trace.Behavior changes:
kustomization.yaml; the source manifest keeps its bytes.images:/replicas:values now refuse the folder (they'd failkustomize build).Type of Change
Testing
task test; coverage 73.9% → 74.5%,.coverage-baselineraised)task test-e2e: 53 passed, 0 failed, 8 skipped)Checklist
task lint: 0 issues)docs/design/gitops-api/,docs/architecture.md,docs/configuration.md"Kustomize support" section)Related Issues
None — tracked in
docs/design/gitops-api/README.md(F1 of the feature ladder).Additional Notes
One
images:entry is a shared knob (kustomize semantics): products built on this should present a governed version change as affecting all consumers of the entry. A cross-consumer consistency refusal needs sibling live state and is noted as F2 follow-up work.🤖 Generated with Claude Code