Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emit issues to the root module instead of each module #396

Merged
merged 1 commit into from Aug 29, 2019

Conversation

wata727
Copy link
Member

@wata727 wata727 commented Aug 22, 2019

This pull request changes on how to handle issues found in modules. For example, consider the following configuration file:

# main.tf
module "ec2" {
  source = "./module_path"
  instance_type = "t1.2xlarge"
}
# module_path/main.tf
variable "instance_type" {}

resource "aws_instance" "foo" {
  ami = "ami-123456"
  instance_type = var.instance_type
}

resource "aws_instance" "bar" {
  ami = "ami-123456"
  instance_type = "t1.2xlarge"
}

As of v0.10.1, TFLint returns the result:

$ tflint --module
ec2/main.tf
        ERROR:6 instance_type is not a valid value (aws_instance_invalid_type)
        ERROR:11 instance_type is not a valid value (aws_instance_invalid_type)

After this change, you get the following results:

$ tflint --module
main.tf
        ERROR:4 instance_type is not a valid value (aws_instance_invalid_type)

What happens?

Previously issues found inside a module were reported along with the line number for that module. This has the advantage of keeping the implementation simple, but there are various disadvantages in practice.

In a simple example, an issue that already exists in the module cannot be properly ignored by the caller (root module). This is because the tflint-ignore annotation needs to be written for the line that reported the issue.

Another major reason is the lack of compatibility with editor integration. Since there are no reported lines in the file being edited, it is difficult for the user to find issues caused by module arguments.

By reporting an issue to the root module that declares the module argument, you can easily see what issues the argument causes under the module. To achieve this, it internally knows how the module arguments are propagated to the child module. This means that issues that are not caused by module arguments will be ignored, as in the example above. Such issues should be found by inspecting the module itself.

@wata727 wata727 added this to the v0.11.0 milestone Aug 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant