`Env` variables are not being set for remote shell provisioners

[Geogboe]

Overview of the Issue

Usage of env option with shell provisioners was added: #11569. This works when using the shell-local provisioner but with remote shell provisioners the variables are not being set and no error is being thrown. Only variables defined in environment_vars are being set so it appears that env values are being ignored for these provisioners. I'm presuming that all the shell provisioners should be able to work with this env option because all of their docs were updated to reference it...but maybe this wasn't the intention?

Reproduction Steps

1. Create packer template and use the windows-shell or powershell provisioner.
2. Defined a map of environment variables for the env option.
3. Attempt to access those environment variables in either a script or an inline command in the provisioner and they will not be set.

Packer version

packer version
Packer v1.8.0

Simplified Packer Template

  provisioner "shell-local" {
    env = {
      "MY_SECRET" : "foo"
    }
    inline = [
      "echo This one works because it's local",
      "echo yo, my secret is %MY_SECRET%"
    ]
  }

  provisioner "windows-shell" {
    env = {
      "MY_SECRET" : "foo"
    }
    inline = [
      "echo This is remote and doesn't work",
      "echo yo, my secret is %MY_SECRET%",
    ]
  }

  provisioner "powershell" {
    env = {
      "MY_SECRET" : "foo"
    }
    inline = [
      "Write-Host \"This is remote and doesn't work\"",
      "Write-Host \"yo, my secret is $env:MY_SECRET\""
    ]
  }

Output

packer build -var-file .auto.pkrvars.hcl .\env_test.pkr.hcl
...
==> null.debug-provisioner: Running local shell script: <sensitive>\AppData\Local\Temp\packer-shell238556163.cmd
    null.debug-provisioner: <sensitive>\dev\bugs\packer-env>echo This one works because it's local
    null.debug-provisioner: This one works because it's local
    null.debug-provisioner: <sensitive>\dev\bugs\packer-env>echo yo, my secret is foo
    null.debug-provisioner: yo, my secret is foo
...
==> null.debug-provisioner: Provisioning with shell script: <sensitive>\AppData\Local\Temp\windows-shell-provisioner2209675043
    null.debug-provisioner: C:\Users\packer>echo This is remote and doesn't work
    null.debug-provisioner: This is remote and doesn't work
    null.debug-provisioner: C:\Users\packer>echo yo, my secret is
    null.debug-provisioner: yo, my secret is
...
==> null.debug-provisioner: Provisioning with powershell script: <sensitive>\AppData\Local\Temp\powershell-provisioner3775875442
    null.debug-provisioner: This is remote and doesn't work
    null.debug-provisioner: yo, my secret is

Workaround

I'm not an expert but it looks like the problem might be with this createFlattenedEnvVars method defined in https://github.com/hashicorp/packer-plugin-sdk/blob/f7d4bf877a45a9d253c548e902d6d1bd7d907d23/shell-local/run.go#L174. While the shell-local provisioner appears to use this method as is, the windows-shell, and powershell (and even shell) provisioners appear to redefine it and do custom things.

The important bit seems to be this change here: https://github.com/hashicorp/packer-plugin-sdk/blob/f7d4bf877a45a9d253c548e902d6d1bd7d907d23/shell-local/run.go#L209 that was made only in the SDK and not in the other provisioners. So, as a test I add this to the powershell provisioner and it seemed to fix it

for k, v := range p.config.Env {
    envVars[k] = strings.Replace(v, "'", `'"'"'`, -1)
}

Operating system and Environment details

Windows 11 build 10.0.22000.0 x64
Target OS: Windows Server 2019
Powershell v7.2.1

[smaddock]

Confirmed the same for *nix shells as well.
Packer 1.8.0
Local shell: zsh 5.8 (macOS 12)
Target shell: bash 5.1.4 (Deb 11)

[github-actions]

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.