Support array index notation in --set flag#219
Conversation
📝 WalkthroughWalkthroughThe Changes--set flag parsing refactor and dependency updates
Sequence Diagram(None—these are straightforward parsing and validation updates without complex multi-component orchestration flows.) Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Replace custom path parsing (strings.Split + unstructured.SetNestedField) with Helm's strvals.Parse, which handles the full --set syntax including bracket notation like `central.spec.central.defaultTLSSecret[0].name=val`. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@cmd/deploy.go`:
- Around line 140-149: The prefix validation for the "spec." guard only checks
the first key extracted from the expression before the equals sign, but
strvals.Parse handles comma-delimited multi-assignment expressions that can
contain multiple key=value pairs. To fix this, validate all keys in the
expression, not just the first one: split the entire expr by commas to extract
each individual assignment, validate that none of the keys in any of these
assignments start with "spec." (checking the portion before each equals sign),
and then proceed with the strvals.Parse call. This ensures that expressions like
"central.a=1,spec.b=2" properly reject the second assignment instead of only
validating the first key.
🪄 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: Path: .coderabbit.yml
Review profile: CHILL
Plan: Enterprise
Run ID: 1160977c-6262-46fb-a784-292b8bc0ba9f
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (3)
cmd/deploy.gocmd/deploy_test.gogo.mod
Move the spec.* rejection check to run after strvals.Parse, inspecting the parsed map for a top-level "spec" key. This catches comma-delimited multi-assignment expressions (e.g. "central.a=1,spec.b=2") that previously bypassed the guard which only checked the first key. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
cmd/deploy_test.go (1)
263-267: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winAssert config is unchanged after rejected
--set.At Line 265, you already assert an error for forbidden
specpaths, but the test doesn’t verify state safety. Add an assertion thatcfgis still the default config to prevent silent partial-mutation regressions.Proposed test hardening
t.Run(tt.name, func(t *testing.T) { cfg := deployer.NewConfig() + initial := deployer.NewConfig() cmd := newDeployCmd(&cfg) err := cmd.ParseFlags(tt.args) require.Error(t, err) assert.Contains(t, err.Error(), "spec") + assert.Equal(t, initial, cfg) }) } }🤖 Prompt for 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. In `@cmd/deploy_test.go` around lines 263 - 267, The test verifies that ParseFlags rejects the forbidden spec path but doesn't ensure the config remains in its default state. After the existing require.Error and assert.Contains assertions in this test block, add an assertion that compares the cfg variable to a freshly created default config (created the same way as the initial cfg := deployer.NewConfig() at the start of the test) to verify that no partial mutations occurred during the failed ParseFlags call.
🤖 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.
Nitpick comments:
In `@cmd/deploy_test.go`:
- Around line 263-267: The test verifies that ParseFlags rejects the forbidden
spec path but doesn't ensure the config remains in its default state. After the
existing require.Error and assert.Contains assertions in this test block, add an
assertion that compares the cfg variable to a freshly created default config
(created the same way as the initial cfg := deployer.NewConfig() at the start of
the test) to verify that no partial mutations occurred during the failed
ParseFlags call.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Enterprise
Run ID: 688497f4-bd89-4aed-879b-9d3096090a79
📒 Files selected for processing (2)
cmd/deploy.gocmd/deploy_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
- cmd/deploy.go
Summary
strings.Split+unstructured.SetNestedField) with Helm'sstrvals.Parse, which handles the full--setsyntax including bracket notation likecentral.spec.central.defaultTLSSecret[0].name=frontend-certunknown field "spec.central.defaultTLSSecret[0]"because[0]was treated as part of the map keyTest plan
--settests pass (backward compatible)go build ./...,go vet ./...,go mod tidyclean🤖 Generated with Claude Code
Summary by CodeRabbit
--setflag now supports array index notation (for example,...field[0].name=...) when updating deployment configuration.--setparsing forkey.path=valueupdates for more consistent value handling.--setnow rejects updates that targetspecpaths to prevent unintended configuration changes.