Packer: "Variables not allowed" with HCL2 and Packer 1.5.3

[jfpanisset]

Packer 1.5.3

Looking at the documentation at:

https://packer.io/guides/hcl/variables

Given foo.pkr.hcl file:

variable "myvar" {
    type    = string
    default = "myvalue"
}

when I run packer 1.5.3:

$ packer build  .

==> Builds finished but no artifacts were created.

But trying to assign to the variable on the command line or via an environment variable errors out with "Error: Variables not allowed" :

$ packer build  -var myvar=newval .
Error: Variables not allowed

  on <value for var.myvar from arguments> line 1:
  (source code not available)

Variables may not be used here.



==> Builds finished but no artifacts were created.

or

$ PKR_VAR_myvar=newval ../packer build  .
Error: Variables not allowed

  on <value for var.myvar from env> line 1:
  (source code not available)

Variables may not be used here.



==> Builds finished but no artifacts were created.

Am I just getting the syntax wrong?

[azr]

Hello @jfpanisset, thanks for opening ! And trying out HCL2 :D. Yes that is a bug -- but !

PKR_VAR_myvar=newval or -var myvar=newval in the command line in HCL is sort the equivalent of doing:

variable "myvar" {
    default = newval // no such newval variable
}

For it to work for now you can quote the strings, for example:

Doing PKR_VAR_myvar='"newval"' or -var myvar='"newval"'

I do agree here that these should be interpreted as strings and we will try to come with a fix soon !

[jordan1818]

Hello there @azr

I am having the same issue too, but on 1.5.4 and this issue still persists, even with the work around. I am using the CLI as -var aws_access_key='"AWSAccessKey123!"'

Error: Variables not allowed

  on <value for var.aws_access_key from arguments> line 1:
  (source code not available)

Variables may not be used here.

Is there another workaround or do we have an ETA on this fix?

I look forward to hearing from you

[jfpanisset]

This explains why special characters (such as @) in my variable values on the command line would trigger an extra error about an invalid character in a variable name.

In my case the double quoting workaround seems to be working with packer 1.5.4 on Linux/x64 using either the VAR_PKR_myvar='"newval"' or -var myvar='"newval"' syntax.

[azr]

Hey everyone, @nywilken ( and me ) fixed this in #8834, nice ! I'm merging that PR and before we release a new binary, binaries from the PR can be found here

[jfpanisset]

I can confirm that with this fix I no longer need to use the -var var_name='"VAR_VALUE"', I can use -var var_name=VAR_VALUE as expected. Thank you!

[nywilken]

@jfpanisset thanks for testing out the latest fix and for the time in reporting the issue. Cheers!

[ravenium]

I ran into this last night trying to spin up an in image that has to be passed AWS credentials in order to download an ECR repo. For the life of me, I couldn't get it to work. I had an environment_variables[] block in my shell provider, and I received the errors above when trying to add "SOME_VAR=${var.my_var}" and having VAR_PKR_my_var = $AWS_LOGIN_CRED in local env.

I tried the double quoting trick above and it ended up literally passing a string of "$AWS_LOGIN_CRED".

I tried even literally pasting the credentials into the script (eww) and it mangled them due to special characters, causing AWS commands to fail.

I ended up launching the builder with an instance role as a workaround, but man was that frustrating! It sounds as if this is getting fixed in 1.5.5.

Side note, why are env vars only allowed to be read with ENV_PKR_ prefixes? Whatever happened to the equivalent of {{env SOME_ENV_VAR}} in v1? It might be a corner case, but it'd be useful if you need to read something output by another tool without creating a clone env var_pkr_ var.

[azr]

Hey @ravenium sorry you had this issue and that this was confusing for you ! Checkout Packer the docs on input variables & env - the prefix is PKR_VAR_ - I'm not sure if it was a problem you had 🙂.

Whilst I don't have strong opinions agains porting {{env SOME_ENV_VAR}} to HCL2. Not doing so helps us remain consistent with Terraform ( Terraform input variables docs ).
I think this choice was made for Terraform to make sure variable naming and setting is explicit and to make these variables sorted, grouped and therefore easy to find, it requires a tiny bit of extra work on the setup but makes it super easy to maintain and I think it's a good idea.

Also in general I think avoiding template calls ( {{ }} calls ) is a good thing in order to keep the "variables layer" into HCL2. As it makes things super easy to implement and maintain and it untangles templating code from actual builder/provisioner code. If it were me I'd move everything there; but I know Packer has a past and things are not that simple 🙂.

---

The TLDR for how input variables work is the following:

1/ Declare a var:

# this can be declared in any *.pkr.hcl file depending on your preference.
# For example in vars.pkr.hcl if you want them all there
# or at the top of the file where it is being used
variable "foo" {
  type = string
  default = ""
}

2/ Set it either from:

• env: PKR_VAR_foo=bar packer ...
• an *.auto.pkrvars.hcl file : packer build folder/

# folder/varfile.auto.pkrvars.hcl
foo = "bar"
# this file needs to be in the same folder as your buildfiles and packer will just parse it as a varfile

• a var argument packer -var-file /home/azr/shared_confs/foo.pkrvars.hcl -var foo=bar ... :

# this file can be anywhere but it's extension needs to be "pkrvars.hcl" ( or ". pkrvars json" for the json format )
foo = "bar"

The further down this list the more priority the setting will have. auto varfiles are sorted in lexical order of their filenames. -var and -var-files are not auto sorted and the last one that sets a variable 'wins'.

⚠️ Note that pkrvars.hcl files have a specific layout and permit setting variables directly without a body.

[ravenium]

Thanks @azr. That'll teach me to write in github without the script in front of me, I had the naming right, just not the memory of naming! I'll give it another try with 1.5.5 now that it's out. Thankfully my branch isn't intended to be prod for a while as they understand that packer's hcl support is an evolving matter.

Sounds like you have a good path for consistency here - I'd be loathe to suggest otherwise. HCL variables look ages less esoteric than current packer ones. I still hope TEMPLATE_DIR will make it in though - not having relative paths for file provisioners is rough!

Thanks again - I'll stop polluting the closed ticket now. :)

[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.