✅ Deploy Preview for zarf-docs canceled.

Codecov Report

❌ Patch coverage is 73.91304% with 6 lines in your changes missing coverage. Please review.

... and 1 file with indirect coverage changes

Overall logic looks good, but worth noting that this PR depends on #4403 as without that change imports will not work since Zarf will look for a values directory.

@Racer159 Can you rebase with main to bring this up-to-date? I want to compare available options but I intend to evaluate any edgecases and otherwise advocate for getting this work merged as-is or similar and then pushing progress thereafter for values maturation.

Updated tests to isolate testing values import and merge behaviors.

I think we should consider UX next:

• zarf dev inspect ignores imports entirely
• zarf package inspect lists the files as they would exist on import instead of the aggregate values.yaml that now lives within the package. Should we mutate this for accuracy around the built package or keep it for backwards transparency?

I think any schema decisions should be part of a separate PR. The docs include mention of the behavior now and we can decide if we want to pursue schema import behaviors.

Adding a thought - Looking at package values at the top level you specify values.files[] and this is a list of paths to package values files for the package. Imports will add items to this list.

Once packaged - this list is slightly less representative - we parse all values files and consolidate into a single values.yaml file in the package.

Options that stand out immediately:
Retain them as they are defined or resolved - zarf package inspect will include the declarative definition but the underlying package will only have a values.yaml
mutate the definition so that zarf package create specifies the packaged file values.yaml and not the original definition.

1 feels more correct while 2 feels most accurate (regarding a built package). I do wonder if we should revisit the original design.... I think there is a third route where we don't consolidate internally to a values.yaml that could be most representative of both scenarios.

I would stay with option 1 after considering the most likely workflows of users.

Users are unlikely to unarchive a package to figure out what is in the values.yaml, and are more likely to run zarf package inspect manifests|values-files. If they get something unexpected, they may run zarf package inspect definition to see which files were included. By removing what the creator wrote, we make it more difficult to view what was used at create time.

Similarly, I would rather compile the files at create time. It's simpler to implement, and while keeping them separate might give higher fidelity to someone viewing an unarchived package, I wouldn't necessarily want to encourage this, and would rather introduce inspect commands if there is that need.