Fix unmarshalling of Helm values yaml file

[rquitales]

Proposed changes

Previously, we used gopkg.in/yaml.v3 as our yaml library to unmarshal helm values. This library allows unmarshalling complex mapping key types, which would be unmarshalled into map[any]any types instead of map[string]any.

Upstream Kubernetes has mostly switched to using their yaml fork (sigs.k8s.io/yaml), which upstream Helm is also using. sigs.k8s.io/yaml does not handle complex mapping key types, and instead, will try to marshal these keys as strings instead. In short, they convert yaml to json before marshaling/unmarshaling into a struct. To maintain compatibility with upstream Helm, this PR switches our yaml library to the Kubernetes fork to ensure the unmarshalled result is comparable.

Example yaml:

key1: value1
2: value2

With gopkg.in/yaml.v3 unmarshaling:

objType: map[any]any

With sigs.k8s.io/yaml:

objType: map[string]any

Changes made:

• Switched yaml package to sigs.k8s.io/yaml
• Expanded integration test case to incorporate complex mapping types in the values file, ensuring resolution of panics

Related issues (optional)

Fixes: #2814
Fixes #2684

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (22663e6) 24.64% compared to head (d3700d0) 24.64%.
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2815   +/-   ##
=======================================
  Coverage   24.64%   24.64%           
=======================================
  Files          48       48           
  Lines        9710     9710           
=======================================
  Hits         2393     2393           
  Misses       7160     7160           
  Partials      157      157           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[t0yv0]

I'm surprised of this behavior of "gopkg.in/yaml.v3", so it would result in map[any]any in the uncommon case that keys have non-strings in them? Or also in the common case? Is it possible for the change to introduce errors that were not there before?

LGTM of course looks very reasonable and surgical. But as you know I do not have a good handle on this codebase to have a sense of what could break.

[rquitales]

I'm surprised of this behavior of "gopkg.in/yaml.v3", so it would result in map[any]any in the uncommon case that keys have non-strings in them?

The YAML specification is indeed complex and nuanced. The original author of sigs.k8s.io/yaml elaborates on the early challenges faced in the Kubernetes project in this blog post: The Right Way to Handle YAML in Golang.

Essentially, the logic go-yaml uses to unmarshal to Go structs differs from the standard library JSON package, creating an impedance mismatch. This discrepancy arises because upstream Kubernetes and Helm libraries internally utilize JSON unmarshaling to handle YAML files.

Or also in the common case? Is it possible for the change to introduce errors that were not there before?

As for the potential introduction of errors, I believe this change wouldn't introduce new errors. This PR specifically addresses the unmarshalling of custom helm values in the Helm Release resource, and is essentially scoped to 1 line of usage (ref: provider/helm_release.go#L298). Prior to this adjustment, the provider would have encountered a panic if a mapping key was anything other than a string. However, using normal Kubernetes or Helm wouldn't pose an issue, as the underlying sigs.k8s.io/yaml package attempts to convert non-string keys to strings. This PR essentially aligns the values file parsing with the approach used upstream by Helm.