cannot unmarshal number into Go struct field ChartVersion.appVersion of type string

[juliendangers]

Terraform Version

Terraform v0.12.12

• provider.helm v0.10.4

Affected Resource(s)

• helm_repository

Terraform Configuration Files

data "helm_repository" "keda" {
  name = "keda"
  url  = "https://kedacore.azureedge.net/helm"
}

Debug Output

Error: Looks like "https://kedacore.azureedge.net/helm" is not a valid chart repository or cannot be reached: error unmarshaling JSON: while decoding JSON: json: cannot unmarshal number into Go struct field ChartVersion.appVersion of type string

It worked perfectly in previous versions (<= 0.12), but since appVersion is commit hash in keda repo, if you added number type restriction, it cannot work. The repository is valid => https://kedacore.azureedge.net/helm/index.yaml

Expected Behavior

Since the spec does not provide type information, we should not expect it to be a number. I've seen many things like vx.x.x

Actual Behavior

Crash while attempting to convert a string into a number

Steps to Reproduce

1. terraform plan

[Carles-Figuerola]

We are finding the same problem since the release of 0.10.3. We are wondering if the parsing of the file is being done differently because of this upgrade: 107d7de

One theory in our case is when a version string happens to look like 319e199, which might be parsed as an integer instead of a string, which causes a type mismatch down the code.

[rehevkor5]

Yes, but I think you meant that it's getting parsed as float. I believe this is also related to go-yaml/yaml#290 which fixed gopkg.in/yaml.v2 to resolve tags in a way which more accurately matches the YAML 1.2 spec. Specifically, that the [-+] is optional in floats.

Specifically, the error we were getting was:

Looks like "https://ourrepo.example.com/foo/" is not a valid chart repository or cannot be reached: error unmarshaling JSON: while decoding JSON: json: cannot unmarshal number into Go struct field ChartVersion.version of type string

The problematic version in question is coming from the https://ourrepo.example.com/foo/index.yaml file that Helm provider is downloading.

We happen to be using Artifactory as our repo provider, and it looks like there is an existing bug about this issue: https://www.jfrog.com/jira/browse/RTFACT-20334 However, it might be good to have a workaround on the Helm Provider side as well.

[rehevkor5]

Also, I don't know exactly where this should be done, but ideally the YAML->JSON code would be able to produce a more informative error message, or there could be a setting for increased logging verbosity. As it stands, the output does not provide enough information to identify which specific value or line caused the problem.

[zodrog]

Same exact problem here with kedacore.

As a workaround I had to downgrade to version 0.9.1

provider "helm" {

kubernetes {
host = "${module.kubernetes.host}"

client_certificate              = "${base64decode(module.kubernetes.client_certificate)}"
client_key                      = "${base64decode(module.kubernetes.client_key)}"
cluster_ca_certificate          = "${base64decode(module.kubernetes.cluster_ca_certificate)}"

}

install_tiller = "true"
service_account = "tiller"
tiller_image = "gcr.io/kubernetes-helm/tiller:v2.13.0"
namespace = "kube-system"
version = "0.9.1"

}

Cheers

[mcuadros]

Closing this issue since is making reference to a version based on Helm 2, if this is still valid to the master branch please reopen it. Thanks.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!