-
Notifications
You must be signed in to change notification settings - Fork 359
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
Capability to only run explicitly-provided rules #875
Capability to only run explicitly-provided rules #875
Conversation
Makes sense, but I think the e.g.
|
I like that, making the change. |
Whoops, sorry. I misread. You wanted it to replace the use of |
@wata727 I've modified the CLI option to accept rules like the following: tflint --only aws_instance_invalid_type I've also added a warning message when Let me know what you think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I have some suggestions, please review this one.
It is also useful to debugging/developing rules 👍
I also noticed that using the ec2.tf resource "aws_instance" "foo" {
instance_type = "t4.micro"
}
resource "aws_instance" "bar" {
instance_type = "t1.micro"
} .tflint.hcl rule "aws_instance_invalid_type" {
enabled = true
}
In this case, it may be useful to ignore the In order to do that, we have to change the |
This should be fixed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your great contribution. I have some suggestions, but these are not blocking to merge.
Merging this pull request may be a little later, as some bug fixes are planned.
} | ||
} | ||
return ret | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about simply ignoring the former rule configs? The following is an example:
+ // All based configuration will be ignored
+ if !bDisabledByDefault {
for k, v := range a {
ret[k] = v
}
+ }
for k, v := range b {
// HACK: If you enable the rule through the CLI instead of the file, its hcl.Body will not contain valid range.
// @see https://github.com/hashicorp/hcl/blob/v2.5.0/merged.go#L132-L135
+ if prevConfig, exists := a[k]; exists && v.Body.MissingItemRange().Filename == "<empty>" {
- if prevConfig, exists := ret[k]; exists && v.Body.MissingItemRange().Filename == "<empty>" {
ret[k] = v
// Do not override body
ret[k].Body = prevConfig.Body
} else {
ret[k] = v
}
}
@@ -65,6 +66,23 @@ CLI flag: `--force` | |||
|
|||
Return zero exit status even if issues found. TFLint returns non-zero exit status by default. See [Exit statuses](../../README.md#exit-statuses). | |||
|
|||
## `only` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you write about the key in the configuration file, it may be better to write disabled_by_default
here (CLI flag description seems to be --only
)
Context
We have a use case where we only want to run specific rules against our terraform repositories, and leave further linting to other workflows. As such, we need a way to disable all default rules, and only allow the ones we've specifically enabled via the config or CLI arguments.
What I Changed
A new argument/config option called
--only
(boolean) has been added, which is used in theNewRules
part of therules/provider.go
to determine whether a rule should be enabled if it wasn't found in the provided config.CLI example usage
Config example usage
Additionally, I've added a warning message when this mode is enabled and no rules were provided.
Tests have also been updated to reflect the new option.