Support array index notation in --set flag by porridge · Pull Request #219 · stackrox/roxie · GitHub
Skip to content

Support array index notation in --set flag#219

Merged
porridge merged 2 commits into
mainfrom
nested-set
Jun 24, 2026
Merged

Support array index notation in --set flag#219
porridge merged 2 commits into
mainfrom
nested-set

Conversation

@porridge

@porridge porridge commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Summary

  • 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=frontend-cert
  • Previously this would fail with unknown field "spec.central.defaultTLSSecret[0]" because [0] was treated as part of the map key

Test plan

  • Existing --set tests pass (backward compatible)
  • New test for array index notation
  • go build ./..., go vet ./..., go mod tidy clean

🤖 Generated with Claude Code

Summary by CodeRabbit

  • New Features
    • The --set flag now supports array index notation (for example, ...field[0].name=...) when updating deployment configuration.
  • Bug Fixes
    • Improved --set parsing for key.path=value updates for more consistent value handling.
    • --set now rejects updates that target spec paths to prevent unintended configuration changes.
  • Chores
    • Updated project dependencies, including Kubernetes API machinery, container registry tooling, and related libraries.

@coderabbitai

coderabbitai Bot commented Jun 23, 2026

Copy link
Copy Markdown

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>

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 6887804 and 494672c.

⛔ Files ignored due to path filters (1)
  • go.sum is excluded by !**/*.sum
📒 Files selected for processing (3)
  • cmd/deploy.go
  • cmd/deploy_test.go
  • go.mod

Comment thread cmd/deploy.go Outdated
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>

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
cmd/deploy_test.go (1)

263-267: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick win

Assert config is unchanged after rejected --set.

At Line 265, you already assert an error for forbidden spec paths, but the test doesn’t verify state safety. Add an assertion that cfg is 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

📥 Commits

Reviewing files that changed from the base of the PR and between d6a2882 and 747797a.

📒 Files selected for processing (2)
  • cmd/deploy.go
  • cmd/deploy_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
  • cmd/deploy.go

@porridge porridge merged commit e528172 into main Jun 24, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants