Open akerone opened 1 year ago
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.
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.
Any updates?
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 😦
This is still an very annoying issue !!
I just uninstalled. There are better packages out there
for Terraform?
Versions
Extension
VS Code
Operating System
Windows
WSL
Terraform Version
Steps To Reproduce
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