Even if they don't, they will need to change the environment variables when switching between workspaces, presumably without closing the IDE. It has some really bad UX implications stemming from the fact that most people launch their IDEs context/environment-less (via icon from a desktop, menu bar etc.). I would not go as far as propagating everything.
Then Terraform can find az and any other similar auth providers. which has no write permissions for non-admins
#ERROR CODE 17099 AUTHENTICATION REQUIRED WINDOWS#
os.TempDir would otherwise fall back to C:\Windows on Windows This allows Terraform to create crash log in the desired temp directory This allows Terraform to find custom-built providers Environment variables to pass through to Terraform I mean even if you do store variables locally, then the sensitive ones should really be stored in something like envchain, so I'm more inclined to support that, as opposed to passing individual variables. Maybe we just discourage this is as a bad practice and make folks approach it either via wrappers, or by making terraform commands work out of the box (e.g.
And allowing user to set environment variables manually somewhere in settings doesn't make a great UX either, especially when they need to switch between workspaces. I'm not sure there's any decent way we can support that, because passing environment variables between whatever process launches the IDE, the IDE, plugin system and terraform-ls is not trivial. There may be users which don't use wrappers like the one you mentioned, but set variables manually. Does that sound like a decent short-term solution? We can also prioritize the UI config option for setting the Terraform path in VSCode and try to construct sh -c "string" or cmd.exe /c "string" (depending on the OS) on the fly for the user, before setting it as a flag. The only caveat is that it needs some patches to work on Windows, e.g. Good catch! I'm not too excited about flags which expect string with spaces (or any kind of arrays), but it is a solution and think we could use something like go-shellwords to parse the string. However it expects a single executable I think. Ideally obtaining schema shouldn't require state at all (and hence shouldn't require auth) IMO, but we can't really fix this in Terraform core retrospectively (in past versions), so we will need to have a decent solution before this is addressed in core. That said you should be able to init outside of VSCode for the time being.ĭo you mind sharing more details about the problem you're running into? Ideally a snippet of a log like the above? I'm aware that the extension also has terraform init in the command palette - and I agree that we should reflect the reality you described there and somehow allow users to pass the configuration. Obtaining the schema does require the workspace to be initialized, but terraform init (which would require credentials and access to the remote state) can run outside of the IDE. ġ 08:22:00 exec.go:172: terraform run (/usr/local/bin/terraform, in "/var/folders/fb/k_9ystyd08j934qcxmyv0wjc0000gp/T/", pid 19252) finished with exit code 0ġ 08:22:00 exec.go:180: Starting /usr/local/bin/terraform in "/private/var/workspace/tf-test/github".ġ 08:22:02 exec.go:172: terraform run (/usr/local/bin/terraform, in "/private/var/workspace/tf-test/github", pid 19278) finished with exit code 0
0 kommentar(er)
