Skip to content

ZEP-0021: propose valuesFrom and pathing updates to Zarf values - #66

Open
Racer159 wants to merge 2 commits into
zarf-dev:mainfrom
Racer159:feat/values-from
Open

ZEP-0021: propose valuesFrom and pathing updates to Zarf values#66
Racer159 wants to merge 2 commits into
zarf-dev:mainfrom
Racer159:feat/values-from

Conversation

@Racer159

@Racer159 Racer159 commented Aug 5, 2026

Copy link
Copy Markdown
Contributor
  • One-line PR description: This updates the Zarf Values ZEP by proposing a new valuesFrom syntax as well as updated pathing for existing sourcePath and targetPaths.
  • Other comments: None

Signed-off-by: Wayne Starr <me@racer159.com>
Signed-off-by: Wayne Starr <me@racer159.com>

@AustinAbro321 AustinAbro321 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thank you for the proposal. I like the problem statement of abstracting common actions use cases

@@ -379,6 +445,8 @@ This feature will require a lot of design work to ensure that it has a solid use

We could patch the existing Variables/Constants/Templates paradigm to align more with Helm paradigms but this would not address the other issues that exist with Variables/Constants/Templates. Features like `autoIndent` and `setVariables` have always been limiting to users and creating a new way to set values will allow us to design something that is more user friendly (especially since many Zarf users are also Helm users).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

What are your thoughts would be on a custom function similar to Helm lookup ?

Functionally, I think we could make it generally mirror this proposal, but it's hard for me to say if it makes the UX better or worse.

I do like that the same function would be exposed to actions/charts/manifests

targetPath: .resources # this wins
```

Also, `charts` and `manifests` would accept an optional `valuesFrom` list. Each entry contains required `kind`, `jsonPath`, and `targetPath` fields, with optional `name`, `namespace`, and `enabledPath` fields. `kind` would use the same discovery behavior as cluster wait actions and could be fully qualified when needed. A named source performs a `GET`; omitting `name` performs a `LIST` and makes `.items` available to `jsonPath`. `jsonPath` is evaluated by `client-go` and is written without kubectl's outer braces.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It's unclear to me how manifests will work in this design? Is the target path package values?

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