type checking rule results in error where a warning may be more appropriate

cfn-lint version: 0.3.2

E3012 - “Check resource properties values” is not always an error

While I agree providing strict type checking (#42) is a good thing to do, I think there are 2 distinct cases. One which will cause a stack to fail, which should be an error, and another where nothing bad would happen, it’s just not best practice, this should be a warning.

If there is separate tests for weakly typed values that only generates warnings, this would allow a user to disable this best practice test (if they disagree or don’t care) without having to disable type checking all together.

Example (using lifecycle hook’s HeartBeatTimeout propoerty, which requires and integer:

Error, will cause stack failure:

"MyHook": {
  "Type" : "AWS::AutoScaling::LifecycleHook",
  "Properties" : {
    "HeartbeatTimeout" : false,
    ...
  }
}

Warning, will not cause stack failure, just a potential bad practice:

"MyHook": {
  "Type" : "AWS::AutoScaling::LifecycleHook",
  "Properties" : {
    "HeartbeatTimeout" : "10",
    ...
  }
}

If agreement is reached that this is reasonable/desired I’d be happy to put in a PR.

[jaymccon]

My mistake has been that all the templates I’ve tested against have already gone through a functional test, so the cases where incorrect types do cause errors have already been filtered out.

Apologies for the run around on this one, I’m in agreement that if there’s a chance of type mismatch causing an error it’s a better approach to be strict.

[fatbasstard]

There’s more context in the original issue https://github.com/awslabs/cfn-python-lint/issues/42…

In my experience as long as a property can be resolved into the correct type, CloudFormation does not fail and simply converts the type behind the scenes.

So that is actually not true. It can actually break CloudFormation…

But a possible solution for your use case, that might work better than forking it, could be to create a weaktype check as custom rule and load this in the linting proces (using the -a/--append_rules argument). In this way the check is still in place and you can always use the latest (standard installation) of cfn-lint, so no need to keep a fork up to date.

We are aware that this is a complex rule, and might seem a bit “strict”. But if the specification and the documentation states a property is a String, then it’s a String, so trusting on implicit conversion to happen “automatically” is always a risk.