windows - path problem when invoking packer

[domoran]

Short Description: When invoking packer via terraform under windows, the path settings seem not to be inherited correctly from the terraform process to the packer process. This yields to a "docker not found in path problem" (but also other potential problems), when building packer images.

My Environment:

• Terraform v1.1.7 on windows_amd64
• provider registry.terraform.io/toowoxx/packer v0.10.0
• Docker for Window 4.5.1
• packer 1.8.0

Steps to reproduce:

• Create a new folder and place the two files main.tf and bug.pkr.hcl inside of it
• Make sure terraform, packer and docker are on the path
• execute packer to show that the packer build works fine: packer build bug.pkr.hcl
• execute packer via terraform, by executing: terraform apply -auto-approve

Expected behaviour:

• both builds succeed, terraform plugin will pass the "PATH" environment down to the packer child process to be able to find the docker executable on the path.

Observed behaviour:

• terraform build fails with error message:

Error: Failed to run packer build
│
│   with packer_image.test,
│   on main.tf line 10, in resource "packer_image" "test":
│   10: resource "packer_image" "test" {
│
│ could not run packer command; output: docker.example: output will be in this color.
│
│ Build 'docker.example' errored after 491 microseconds: exec: "docker": executable file not found in %PATH%

I attached the example files and the cmd log to the issue.

main.tf.txt bug.pkr.hcl.txt log.txt

[domoran]

Adding the path explicitly to the packer call works around the problem:

resource "packer_image" "test" {
   environment = {
      path = "C:\\Program Files\\Docker\\Docker\\resources\\bin"
   }
   file = "bug.pkr.hcl"
}

[simaotwx]

Thanks for your report. Please try the keep_environment attribute. If you set it to true, all env variables should get passed through.

[domoran]

Yes, that could serve as a workaround. However this "keep_environment" variable does exist and is turned off by default for a reason - in that case the packer provider does not work as expected, because it assumes packer to be on the path but allows the PATH to be empty.

So my suggestion would be to set sane defaults for PATH and for "TMP" so, that the provider works as exepected. Alternatively we could also put a big hint in the docs to use the keep_environment variable under windows. Not sure how the behaviour under linux is?

What do you think?

[simaotwx]

... in that case the packer provider does not work as expected, because it assumes packer to be on the path but allows the PATH to be empty

In cases where Packer doesn't need external tools (which is the case for most if not all cloud deployments), having no environment passed through works fine.

... So my suggestion would be to set sane defaults for PATH and for "TMP" so, that the provider works as exepected.

That's a good suggestion but the problem here is that it's difficult to really determine for all platforms which environment variables are considered "sane" defaults and which are not.

Not sure how the behaviour under linux is?

While Linux would be able to have the same problem, it appears as though usually Windows users are affected.

What do you think?

I think the best solution is to set keep_environment to true by default and allow turning it off in case it's necessary.

[simaotwx]

Coming back to another point

in that case the packer provider does not work as expected, because it assumes packer to be on the path

Packer is embedded in the provider itself so Packer does not actually need to be in the path. And even if it is, it is not used.