Skip to content

Conversation

@mkcp
Copy link
Contributor

@mkcp mkcp commented Dec 10, 2025

Description

This PR adds the --set-values flag so users can directly override values via the CLI, and begins the path to migrating --set. To do so, we add the --set-variables flag (or versions of it like --deploy-set-variables) and change the description of --set to indicate that it now aliases --set-variables. This alias is just a documentation change in the CLI help text: the flags function identically.

Related Issue

Fixes #4224

Checklist before merging

mkcp added 2 commits December 10, 2025 10:09
…e --set description to indicate it's now an alias for this flag

Signed-off-by: Kit Patella <[email protected]>
@mkcp mkcp self-assigned this Dec 10, 2025
@netlify
Copy link

netlify bot commented Dec 10, 2025

Deploy Preview for zarf-docs ready!

Name Link
🔨 Latest commit 16e01f5
🔍 Latest deploy log https://app.netlify.com/projects/zarf-docs/deploys/6939d8376ed50900088437c9
😎 Deploy Preview https://deploy-preview-4466--zarf-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@codecov
Copy link

codecov bot commented Dec 10, 2025

Codecov Report

❌ Patch coverage is 80.76923% with 10 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/cmd/package.go 52.38% 10 Missing ⚠️
Files with missing lines Coverage Δ
src/cmd/dev.go 46.41% <100.00%> (+1.12%) ⬆️
src/cmd/initialize.go 27.93% <100.00%> (+0.29%) ⬆️
src/cmd/viper.go 54.44% <ø> (ø)
src/cmd/package.go 38.19% <52.38%> (+0.02%) ⬆️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

mkcp added 2 commits December 10, 2025 12:13
Signed-off-by: Kit Patella <[email protected]>
Signed-off-by: Kit Patella <[email protected]>
@mkcp mkcp moved this to In progress in Zarf Dec 10, 2025
@mkcp mkcp marked this pull request as ready for review December 10, 2025 20:56
@mkcp mkcp requested review from a team as code owners December 10, 2025 20:56
Copy link
Member

@brandtkeller brandtkeller left a comment

Choose a reason for hiding this comment

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

migration makes sense - added some thoughts around guardrails natively available in cobra that we might consider.


// Init package set variable flags
cmd.Flags().StringToStringVar(&o.setVariables, "set", v.GetStringMapString(VPkgDeploySet), lang.CmdInitFlagSet)
cmd.Flags().StringToStringVar(&o.setVariables, "set", v.GetStringMapString(VPkgDeploySet), "Alias for --set-variables")
Copy link
Member

Choose a reason for hiding this comment

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

Should we explicitly mark these as deprecated?

cmd.Flags().MarkDeprecated("set", "use --set-variables instead")

Copy link
Member

Choose a reason for hiding this comment

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

Rather than having a separate command as an alias that we mark as deprecated or hide, I think it would be better to use the builtin cobra functionality for aliasing a command. This leads to a more intuitive experience around viper config, and will lead to an easier time aliasing --set-values to --set in the future in the event that variables is fully replaced

For instance
cmd.Flags().StringToStringVarP(&o.setVariables, "set-variables", "set", v.GetStringMapString(VPkgCreateSet), lang.CmdPackageCreateFlagSetVariables)

// Init package set variable flags
cmd.Flags().StringToStringVar(&o.setVariables, "set", v.GetStringMapString(VPkgDeploySet), lang.CmdInitFlagSet)
cmd.Flags().StringToStringVar(&o.setVariables, "set", v.GetStringMapString(VPkgDeploySet), "Alias for --set-variables")
cmd.Flags().StringToStringVar(&o.setVariables, "set-variables", v.GetStringMapString(VPkgDeploySet), lang.CmdInitFlagSetVariables)
Copy link
Member

Choose a reason for hiding this comment

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

Given this alias - do we need to mark these flags as mutually exclusive? I understand this to create a last-write-wins scenario if there were to be both used?


// Init package set variable flags
cmd.Flags().StringToStringVar(&o.setVariables, "set", v.GetStringMapString(VPkgDeploySet), lang.CmdInitFlagSet)
cmd.Flags().StringToStringVar(&o.setVariables, "set", v.GetStringMapString(VPkgDeploySet), "Alias for --set-variables")
Copy link
Member

Choose a reason for hiding this comment

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

Rather than having a separate command as an alias that we mark as deprecated or hide, I think it would be better to use the builtin cobra functionality for aliasing a command. This leads to a more intuitive experience around viper config, and will lead to an easier time aliasing --set-values to --set in the future in the event that variables is fully replaced

For instance
cmd.Flags().StringToStringVarP(&o.setVariables, "set-variables", "set", v.GetStringMapString(VPkgCreateSet), lang.CmdPackageCreateFlagSetVariables)

cmd.Flags().StringToStringVar(&o.createSetVariables, "create-set", v.GetStringMapString(VPkgCreateSet), lang.CmdDevFlagSet)
cmd.Flags().StringToStringVar(&o.deploySetVariables, "deploy-set", v.GetStringMapString(VPkgDeploySet), lang.CmdPackageDeployFlagSet)
cmd.Flags().StringToStringVar(&o.createSetVariables, "create-set", v.GetStringMapString(VPkgCreateSet), "Alias for --create-set-variables")
cmd.Flags().StringToStringVar(&o.createSetVariables, "create-set-variables", v.GetStringMapString(VPkgCreateSet), lang.CmdDevFlagSetVariables)
Copy link
Member

Choose a reason for hiding this comment

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

IMO we shouldn't add the variables verbiage to create time templates. Generally I think we should refer to these as package templates. I just noticed that Zarf is inconsistent right now since we call them package variables in this flag, and package templates in our docs. Still, I don't think we'll ever have two types of package templates, at least not in the same API version, so I'm not sure extra verbosity is helpful.

VPkgDeployNamespace = "package.deploy.namespace"
VPkgRetries = "package.deploy.retries"
VPkgDeployValues = "package.deploy.values"
VPkgDeploySetValues = "package.deploy.set_values"
Copy link
Member

Choose a reason for hiding this comment

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

Currently both package.deploy.values and package.deploy.set_values are in use. Not sure which I prefer, but we should only use one.

v := getViper()
o.setVariables = helpers.TransformAndMergeMap(
v.GetStringMapString(VPkgDeploySet), o.setVariables, strings.ToUpper)
o.setValues = helpers.TransformAndMergeMap(
Copy link
Member

Choose a reason for hiding this comment

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

When there is no transform happening, this function is simply a maps.Copy, lets just use that instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

Add --set-value flag for granular values key overrides

4 participants