value interpreted as int when intended as string

[vdice]

Consider a CI pipeline that hands a commit sha between jobs for the purpose of identifying artifacts named with said sha (usually the "short" version as one might get from git rev-parse --short HEAD).

If said short sha happens to feature only numeric characters, for example, 1194495, and one attempts to set a corresponding value in a chart that consumes this, say via helm install chart --set short_sha=1194495, although helm get values appears to show it as a string, it actually exists in the pod's/underlying container's environment as 1.194495e+06 (meaning, it has understandably been cast to type int.)

Quoting the value on --set doesn't appear to help (helm install chart --set short_sha="1194495") which makes sense as there doesn't appear to be support in the parser for this yet; so the value from helm get values is still unquoted.

(Setting the value directly in the values.yaml file, quoted, does have the desired effect of maintaining the value's... string-ness.)

tl;dr So, I suppose my question is, how/where might one mandate type for a value sent in via --set, using the example provided above as a use case? (Or, can/should this be done in the chart itself when it consumes the value?)

[vdice]

Perhaps it would help to give a concrete example, with output edited to focus on issue.

Here using the deis/workflow-e2e chart (with relevant use of the following cli_version value in pod's template here):

$ helm install workflow-e2e-dev/workflow-e2e --namespace=deis  --set cli_version=1194495
Fetched workflow-e2e-dev/workflow-e2e to workflow-e2e-v2.7.2-dev-20161208215407-sha.f698215.tgz
NAME: reeling-gibbon
...

$ helm get values reeling-gibbon
cli_version: 1194495

$ kd logs -f workflow-e2e tests
CLI_VERSION in env is 1.194495e+06

$ helm install workflow-e2e-dev/workflow-e2e --namespace=deis  --set cli_version="1194495"
Fetched workflow-e2e-dev/workflow-e2e to workflow-e2e-v2.7.2-dev-20161208215407-sha.f698215.tgz
NAME: reeling-ragdoll
...

$ helm get values reeling-ragdoll
cli_version: 1194495

$ kd logs -f workflow-e2e tests
CLI_VERSION in env is 1.194495e+06

(yup, two reelings in a row! 😳 )

[vdice]

Of possible interest, while helm get values displays cli_version: 1194495 via the --set scenario above, when the same is set in a values.yaml file used on install, helm get values more transparently shows how the value has been interpreted as an int (again, understandably):

$ cat values.yaml
cli_version: 1194495
...

$ helm install workflow-e2e-dev/workflow-e2e --namespace=deis -f values.yaml
Fetched workflow-e2e-dev/workflow-e2e to workflow-e2e-v2.7.2-dev-20161208215407-sha.f698215.tgz
NAME: unhinged-ladybird
...

$ helm get values unhinged-ladybird
cli_version: 1.194495e+06
...

Which is to say, there may be another/separate minor issue on displaying the 'true' value used back to the user on helm get values when --set is used.

[technosophos]

I beleive that the real cheater-chearter way to do this is to specify type directly. In YAML, you use type tags (!!string or !!int).

I think you can pass this in set: --set "myval=!!string 1234". But I might be wrong. I've never tried.

[vdice]

@technosophos Thank you for the creative workaround suggestion! I've tried many variations of it but unfortunately, either my bash terminal interprets the un-escaped !! pair as 'run the last command again' or, if I escape these special characters, the value that ends up in the configmap is a literal myval: '!!string 1234' (And that full literal !!string 1234 val is sent down to the container.)

Attempts included:

--set "myval=!!string 1234"
--set 'myval=!!string 1234'
--set "myval=\!\!string 1234"

Do you think it would be encouraged to implement support for parsing quotes such that --set myval='1234' or --set myval="1234" would make sure myval: "1234" results? (Meaning, quoting mandates type string) I'm definitely game to give it a go if so...

[longseespace]

@vdice This issue has been bugging me for a few days now. I ended up escaping the quote like this:
--set myval=\"1234\". Hope this could help you

[vdice]

@longseespace Thank you very much for sending your approach! At first I was mystified by why it wouldn't work for me:

$ helm install workflow-e2e --namespace deis --set cli_version=\"1194495\"
Error: YAML parse error on workflow-e2e/templates/workflow-e2e-pod.yaml: error converting YAML to JSON: yaml: line 18: did not find expected key

Then I remembered to check on how said value is used in the manifest template:

      - name: CLI_VERSION
        value: "{{.Values.cli_version}}"

Sure enough, when I remove the surrounding quotes from the {{.Values.cli_version}}, and try the approach presented, it works (the value is a string).

I guess I'm still wondering why, when setting cli_version=1234, the 1234 value isn't quoted when the manifest is generated (using quoted form above)? Is that where a bug might be? Perhaps the parser is "interfering" when it should not be?

[longseespace]

@vdice Which helm version are you using? I can't seem to reproduce. I'm using latest helm (v2.1.0) and it's working fine for me

[vdice]

@longseespace interesting -- I'm on 2.1.0 as well, though noticing the tiller version commit differs; will try to align and test...

Client: &version.Version{SemVer:"v2.1.0", GitCommit:"b3d812b3462e5ac8192f656c7098b1b54f29ffa3", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.1.0", GitCommit:"b7b648456ba15d3d190bb84b36a4bc9c41067cf3", GitTreeState:"clean"}

update: versions aligned; same behavior as mentioned in #1694 (comment)

[vdice]

I think a fix for #1707 would actually resolve this issue.

(Again note, as mentioned above, that using --set val=\"1234\" does not seem to be compatible if val is quoted in manifest template as "{{.Values.val}}")

[technosophos]

I'm going to close this as a duplicate of #1707, since fixing one will fix both.

[CharlesB2]

For people who came here because they have the issue, you can now use the --set-string argument