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

Redesign inspection model for child/parent modules #193

Open
wata727 opened this issue Sep 5, 2022 · 0 comments
Open

Redesign inspection model for child/parent modules #193

wata727 opened this issue Sep 5, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@wata727
Copy link
Member

wata727 commented Sep 5, 2022

See also terraform-linters/tflint#1477

The current inspection model is supposed to run per module. The advantage of this model is that rules don't have to know about whether they are inspecting the root module or child modules. This worked fine in early designs because the module context is irrelevant when checking for invalid instance types.

However, this design has an issue when implementing rules that depend on the child modules such as terraform-linters/tflint#1477. There are other issues as well. Currently, whether or not an issue emitted from a child module is propagated to the final result is determined by whether or not the module's input variables are included in the range, but this is not trivial.

To address these issues, I think we need to change our current inspection model to inspect a module tree instead of a module. However, we must consider the following issues:

  • Incomplete module tree
    • The module tree is not always complete, unlike Terraform. Sometimes all modules are not included, sometimes only certain modules are ignored. An interface should be provided so that the rule can determine this and implement it appropriately.
  • Consistency of checking against child modules
    • The check against a child module is consistent whether the range of the issue includes the module's input variables. However, allowing rules to control this behavior can lead to inconsistencies and confusion for end users. Also, parsing a module's call tree and emitting an issue to the caller may require a complex interface.
  • Syntactic sugar for rules that don't require module context
    • Not all rules require a module tree, and simple rules should be implemented without concern. We'll need some syntactic sugar to accomplish that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

1 participant