Declared variables not reflected in package preview prompt

[blancharda]

Overview

When overriding a variable using --set at deploy time, the default value (rather than the declared value) is shown in the package preview. The variable is correctly overriden if the user continues with the deploy, and the prompt is technically correct -- it explicitly shows the default value - but the behavior seems unclear / unexpected.

Environment

OS: MacOS Ventura, Ubuntu
App version: 0.22.2

Steps to reproduce

1. Declare a variable in a package
2. Override that variable's default using zarf package deploy --set <var>=<value>
3. Observe the displayed package information at the prompt

Expected result

Variable should indicate the <value> provided via --set

Actual Result

Variable indicates the default value defined int the zarf yaml

Example

zarf.yaml:

kind: ZarfPackageConfig
metadata:
  name: var-example
  architecture: amd64

variables:
  - name: FOO
    default: "BAR"
    prompt: false

Sample deploy prompt:

$ zarf package deploy zarf-package-example.tar.zst --set FOO=BAZ

Saving log file to
/var/folders/xx/xh0zby_504s20_smr55cz0g00000gn/T/zarf-2022-12-14-13-22-43-514321233.log
  ✔  Preparing zarf package zarf-package-example.tar.zst

kind: ZarfPackageConfig
metadata:
  name: var-example
  description: ""
  version: ""
  url: ""
  image: ""
  uncompressed: false
  architecture: amd64
build:
  terminal: fruit-basket.local
  user: ablanchard
  architecture: amd64
  timestamp: Wed, 14 Dec 2022 13:22:20 -0500
  version: v0.22.2
components: []
variables:
- name: FOO
  description: ""
  default: BAR
  prompt: false
constants: []

? Deploy this Zarf package? (y/N)
...

[blancharda]

I think my ideal output would indicate a diff from the defaults -- something like:

default: BAR --> BAZ

But I don't see a good way to get there without hacking apart the yaml printing or (jankily) replacing the in-memory default string.

It's not pretty, and I'm not sure I'm advocating for it... but for discussion's sake..
If we were to move this initialization block for SetVariables into the packager constructor, we could also update the corresponding cfg.Pkg.Variables[?].Default to be something like BAR -> BAZ. Theoretically that should be safe, since we already know the true default value is being replaced according to a flag, and then wherever it was printed, we would see the override as well as the default value for context. That feels like an abuse of the default field though..

[dgershman]

Here is some inspiration which is how Terraform shows diffs on a plan.

[blancharda]

Having the ability to see what a zarf package deploy is going to change in the cluster (perhaps in a similar style to terraform apply as suggested above) would be a huge benefit. Especially during updates and "day 2" deploys.

Should we spin that off into a separate issue?

[Racer159]

Kicking back to 5/9 milestone.

[Racer159]

Also agree @blancharda - we probably wouldn't be able to do it (at least well) on the k8s resources themselves but could diff the package yaml in the package we are about to deploy with the package yaml that is in the package secret (if it exists) in the cluster.

[Racer159]

Kicking back to 5/16 to get more design cycles in

[Racer159]

After design cycles from @Madeline-UX the TODO is:

• Make top-level YAML keys bg bright white fg black when printed

• Use fg dim white to add help text for each top-level YAML key

  • i.e. Variables are configurable values that can be set for a package deployment

• Use fg dim white to add set information to each variable -name line

  • i.e. This variable is set to 'Value value value' from 'zarf-config.toml'
  • The value should be shortened with ellipsis to fit on one line
  • The value should be sanitized if it is a sensitive value

  Design Files

  Figma File - https://www.figma.com/file/MUItIzpzLBLuIyt225Bwgl/Zarf?type=design&node-id=1551%3A57164&t=6r9vpYOF5HhaYeug-1