vscode-terraform
vscode-terraform copied to clipboard
hashicorp
Extension shouldn't check for problems in the .terraform folder
Versions
Extension
v2.24.1
VS Code
Version: 1.71.0 (user setup)
Commit: 784b0177c56c607789f9638da7b6bf3230d47a8c
Date: 2022-09-01T07:36:10.600Z
Electron: 19.0.12
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.19043
Sandboxed: No
Operating System
Windows
Edition Windows 10 Enterprise
Version 21H1
Installed on 27/08/2021
OS build 19043.1415
Experience Windows Feature Experience Pack 120.2212.3920.0
WSL
Ubuntu 20.04.4 LTS
Terraform Version
Terraform v1.2.7
Steps To Reproduce
- Create a new main.tf file
- Use a module like https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/tree/master/examples/safer_cluster_iap_bastion
- terraform init
Expected Behavior
No errors on the "Problems" tab of vscode
Actual Behavior
The extension checks for errors in the .terraform folder, giving an error for file in the "autogen" folder. Looking at the file, it's templated with Jinja so it gives "Argument or block definition required: An argument or block definition is required here." before double curly braces.
My code is correct and the module itself works, so seeing the red ball next to the project and folders because of something in the .terraform folder is really annoying.
Additional context
Hi @akerone! Thank you for taking the time to report this!
To ensure I'm reproducing things correctly, can you share your main.tf that is using the mentioned code? Furthermore, can you add a screenshot of your problems tab?
Related: https://github.com/hashicorp/vscode-terraform/issues/405
This comment is probably also relevant: https://github.com/microsoft/vscode/issues/22289#issuecomment-389926531
I think the right and efficient approach is to extensions provide options to exclude.
Sure!
main.tf:
module "gke_bastion_example" {
source = "github.com/terraform-google-modules/terraform-google-kubernetes-engine/examples/safer_cluster_iap_bastion"
bastion_members = []
cluster_name = "test-cluster"
ip_range_pods_name = "test-range-pods"
ip_range_services_name = "test-range-services"
network_name = "test-kube-network"
project_id = "MY-PROJECT"
region = "MY-REGION"
subnet_name = "test-kube-subnet"
}
problems tab:
As you can see, this is not the only module I'm having this issue with.
Also bear in mind, I've been told by terraform-google-modules that this example is not meant to be used as a module. I'm using it here as an example because it's the easiest way of reproducing this issue.
Thank you for sharing the details.
I managed to reproduce it with the example in the main README.md of the same repository.
data "google_client_config" "default" {}
provider "kubernetes" {
host = "https://${module.gke.endpoint}"
token = data.google_client_config.default.access_token
cluster_ca_certificate = base64decode(module.gke.ca_certificate)
}
module "gke" {
source = "terraform-google-modules/kubernetes-engine/google"
project_id = "<PROJECT ID>"
name = "gke-test-1"
region = "us-central1"
zones = ["us-central1-a", "us-central1-b", "us-central1-f"]
network = "vpc-01"
subnetwork = "us-central1-01"
ip_range_pods = "us-central1-01-gke-01-pods"
ip_range_services = "us-central1-01-gke-01-services"
http_load_balancing = false
network_policy = false
horizontal_pod_autoscaling = true
filestore_csi_driver = false
node_pools = [
{
name = "default-node-pool"
machine_type = "e2-medium"
node_locations = "us-central1-b,us-central1-c"
min_count = 1
max_count = 100
local_ssd_count = 0
spot = false
disk_size_gb = 100
disk_type = "pd-standard"
image_type = "COS_CONTAINERD"
enable_gcfs = false
enable_gvnic = false
auto_repair = true
auto_upgrade = true
service_account = "project-service-account@<PROJECT ID>.iam.gserviceaccount.com"
preemptible = false
initial_node_count = 80
},
]
node_pools_oauth_scopes = {
all = [
"https://www.googleapis.com/auth/logging.write",
"https://www.googleapis.com/auth/monitoring",
]
}
node_pools_labels = {
all = {}
default-node-pool = {
default-node-pool = true
}
}
node_pools_metadata = {
all = {}
default-node-pool = {
node-pool-metadata-custom-value = "my-node-pool"
}
}
node_pools_taints = {
all = []
default-node-pool = [
{
key = "default-node-pool"
value = true
effect = "PREFER_NO_SCHEDULE"
},
]
}
node_pools_tags = {
all = []
default-node-pool = [
"default-node-pool",
]
}
}
I would argue that the problem is more that there are files with *.tf extension which do not actually contain valid Terraform configuration, but are used as templates instead.
See https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/blob/b9287de679592a2adcae4d98dcfee33a001f328b/autogen/main/variables_defaults.tf#L17
All other files within the same folder [correctly] use *.tf.tmpl, which makes the extension ignore these template files.
With that said - have you considered raising this as an issue with the module authors/maintainers?
I'm not entirely against the idea of an ignorelist of some kind, but it may not be trivial to implement right. Presumably, you'd still want to see the diagnostics when you open the relevant file/folder and also expect the diagnostics to be gone e.g. when the file changes (even if it's out of focus or not open at all). We'd also have to check the LSP with regards to expectations between the server and client and ensure we don't violate the protocol.
I see your point and I'll definitely raise an issue with the maintainers of this particular module so that they may resolve it. I wasn't aware that this kind of files should have the *.tf.tmpl extension.
My logic was if the module creators are using the extension they should definitely see the problem, but for me as a module user it brings no joy.
As a temporary workaround, you could configure VS Code to purposely exclude the .terraform folder from being watched using files.watcherExclude:
"files.watcherExclude": {
"**/.terraform/*/**": true,
}
This of course prevents the Terraform Extension from knowing anything about those files (go to definition, intellisense, etc) , so use with caution.
Thanks @jpogran !
That would be an acceptable workaround, although it doesn't seem to work in my machine. I've tried adding it to User, Remote and Workspace and both as **/.terraform/** and **/.terraform/*/** and neither seems to remove the errors. I've also restarted VS Code after each change.
Any other ideas?
A related issue, we get errors in the thousands from .terraform folders after the latest update of terraform plugin. The errors are apparently caused by the fact that we have .tfvars files encrypted with git-crypt which appear in .terraform/* folders in ecrypted format which is causing all these errors:
The files with the errors look, expectedly, like this:
After further investigation I noticed that my previous configuration to File -> Preferences -> Setting -> Watcher Exclude:
wasn't being applied in files.watcherExclude (CTRL+SHIFT+P -> files.watcherExclude):
So apparently the workaround that was being used before isn't working any longer.
Thanks @bzlom.
In my case, I do see it in the settings.json file but it has no effect on the problems being reported.
The watcher settings is relevant in situation when the mentioned files change, but the initial diagnostics and the decision to parse these files the first time comes from the language server, and that is unrelated to any watcher logic.
You could try the indexing.ignorePaths setting but it does not support glob patterns (*), just absolute paths.
"terraform.languageServer.indexing.ignorePaths": [
"/foo/bar/terraform.tfvars"
],
We could introduce a similar setting which does support glob patterns, but I'd first like to better understand git-crypt, the intentions/design and the common workflow. I believe that this must be causing a similar/same problem if you run almost any terraform command within the folder where this invalid/encrypted terraform.tfvars file is - so how would you prevent that? Would there be a possibility of either configuring or otherwise tweaking git-crypt such that the encrypted files are kept under a separate filename, to indicate that these are not valid *.tf or *.tfvars files?
@radeksimko I've tried applying the recommended setting to vscode setting.json file with the full path to one of the .terraform directories and it doesn't seem to work:
"terraform.languageServer.indexing.ignorePaths": [
"/home/terraform/service1/.terraform/"
],
When I hover over this option it tells me This setting cannot be applied in this window. It will be applied when you open a local window. I assume I'm not adding it where I should.
Regarding the workflow of git-crypt:
we push all of our terraform code to github. Our .tf* files contain secrets. In order to ensure the secrets in our .tf* files are encrypted we use git-crypt. Locally (on my machine) the .tf* files are in an unencrypted format. The exception are the files located in the .terraform folder - this folder gets created and populated with encrypted .tf* files after we do a terraform init; terraform plan, which are basically temporary files that terraform requires in order to do its work.
Before one of the latest updates, and I'm not sure if it's the update to terraform plugin or vscode, I wasn't getting any sort of errors from these temporary .terraform folders (which have always contained encrypted files), same goes for the rest of my team.
We could introduce a similar setting which does support glob patterns...
Yes please! I'm working with a deeply nested repo that has well-known "bad" tf files placed intentionally throughout the hierarchy so that terraform cannot be run from that directory.
Here's what worked for me.
settings.json:
"files.exclude": {
"**/.terraform": true,
"**/.terragrunt": true
},
"files.watcherExclude": {
"**/.terraform": true,
"**/.terragrunt": true
},
In the Problems tab, ask it to exclude ignored files:
Has there been any movement on this? I may just need to uninstall this package 😦
