fix: do not warn about export-values parents set only in user or service values

Merged
IL
13d ago
+142-3

Summary

Cover the case where werf service values are exported to a subchart that has the same name as the parent chart, while --values sets the child keys directly. Also stop warning about export-values parent paths that are set only in user or service values.

What

  • New regression test with two fixtures: a parent chart and a dependency with the same name, and export-values from global.werf.images.<image>.{repository,tag} or from werf.repo/werf.tag.<image> to image.{repository,tag}. A --values file sets <dep>.image.{repository,pullPolicy,tag}. Service values (ExtraValues) or --set provide the export sources. The rendered manifest gets repository and tag from the export and pullPolicy from the values file. The stored release config has the --values (and --set with its exports), but not the exported service values.
    • The test fails before #773 (the values file wins). It passes since #773, which applies export-values within each values layer. No further fix was needed for same-name charts, global.* export sources in the root chart, or a dependency packaged as .tgz.
  • The chart-level export pass no longer logs WARN ExportValues parent path not found when the parent path is missing from chart values. The path can be set only in --values, --set* or service values (for werf, always werf.*/global.werf.*), which are exported later per layer, so the warning was printed for every such export that works. It is now a debug message, and it logs the path lookup error instead of the misleading "<key>" is not a table.
  • Behaviour change (minor, log only): a typo in an export-values parent: path is no longer reported as a warning.

Why

With werf, export-values from werf service values to a subchart were overridden by the same keys in --values files. The layer-aware precedence from #773/#774 fixes this; this PR pins the scenario with a test and removes the misleading warning that the same scenario printed.