Terraform: Passing value via -var fails

[hugoduncan]

The following command fails with any terraform .tf files.

$ terraform -d plan  -var "image=1234.dkr.ecr.us-east-1.amazonaws.com/proj:abcdef" 
invalid value "image='1234.dkr.ecr.us-east-1.amazonaws.com/proj:abcdef'" for flag -var: Cannot parse value for variable image ("image='1234.dkr.ecr.us-east-1.amazonaws.com/proj:abcdef'") as valid HCL: At 1:7: illegal char

I would have expected anything after the = to have been assigned to the var image.

$ terraform -v
Terraform v0.7.0

[qnu]

Passing a map also fails:
terraform plan -var 'somemap={ env = "env", service = "zoo" }'
somemap["env"] is empty. terraform v0.7.0

Now using TF_VAR_somemap as the workaround.

[Nomon]

-var git_sha=9af86eacf7656af1279557d0ab887cc52622f37f in terraform apply causes:
invalid value "git_sha=9af86eacf7656af1279557d0ab887cc52622f37f" for flag -var: Cannot parse value for variable git_sha ("git_sha=9af86eacf7656af1279557d0ab887cc52622f37f") as valid HCL: key 'af86eacf7656af1279557d0ab887cc52622f37f' expected start of object ('{') or assignment ('=')

Not sure if intended but a fix is to pass the variables as:
-var 'git_sha="xyz"'

[thatarchguy]

I'm experiencing this as well.
The problem is when it starts with a number for me.

Adding a letter to the start or single quoting like @Nomon described works.

$ terraform plan -var "revision=23d324" deploy
invalid value "revision=23d324" for flag -var: Cannot parse value for variable revision ("revision=23d324") as valid HCL: key 'd324' expected start of object ('{') or assignment ('=')

# adding a letter the the beginning
$ terraform plan -var "revision=test-23d324" deploy
[works]

# using single quote
$ terraform plan -var 'revision="23d324"' deploy
[works]

$ terraform version
Terraform v0.7.0

[hugoduncan]

Adding a letter doesn't seem to be a workaround, as terraform doesn't have any substring function, iiiuc.

I'm having trouble coming up with something that works when interpolating in value from the environment, e.g. for:

terraform plan -var revision="${revision}" deploy

I'm resorting to generating a script with the command that uses the single quotes, and then calling the script.

[hugoduncan]

Possibly related, passing a number to a var requires single quoting too, otherwise an error results:

* variable host_port should be type string, got number

[Nomon]

@hugoduncan the single quotes are there to prevent shell from eating the double quotes. -var foo=\"${bar}\" should do the same while allowing interpolation.

[thecodeassassin]

when i pass a location to a file as a var it fails as well:

terraform $OPERATION \
    state "${ENVIRONMENT}.tfstate" \
    -var "credentials='../credentials.json'" \

invalid value "credentials='../credentials.json'" for flag -var: Cannot parse value for variable credentials ("credentials='../../gce_credentials/staging/credentials.json'") as valid HCL: At 1:13: illegal char

This happens since i upgraded to 0.7.0

[thatarchguy]

Looks like it stems from
https://github.com/hashicorp/terraform/commit/681d94ae207b0ff780642d68e98a518eb27eefce

The author explains that a special check was made for CLI supplied variables

In order to continue supporting the -var "foo=bar" type of variable
flag (which is not valid HCL), a special case error is checked after HCL
parsing fails, and the old code path runs instead.

Maybe a problem exists in the special check when the variable starts with a number? I'm not too familiar with Go.

[thecodeassassin]

Looks like it stems from
681d94a

This is correct, what happens is that it tries to load the path i am supplying as a variable to the parseVarFlagAsHCL method which causes it to read it as a file. It shouldn't read it as a file at all since i just want to supply the path as a variable (to provide a path to the credentials file needed to authenticate against google cloud). @jen20 Can you confirm this?

I would say this is a critical bug because it makes 0.7.0 unusable for me.

[anosulchik]

We noticed this issue at terraform 0.7.2.

[plentz]

@hugoduncan the issue you're talking about is #7962

[hashibot[bot]]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.