More intelligent determination of Cfn templates

[kddejong]

Today any passed in file will be linted even if that file isn't YAML or JSON and/or if that YAML/JSON file is a CloudFormation template. Request is to add a parameter to cfn-lint that will validate that a YAML/JSON template is a CloudFormation template before linting it.

[atkinsonm]

I've adopted the pattern of isolating my CloudFormation templates to a separate folder for a similar reason (e.g. to avoid errors running cfn-lint on an Ansible playbook). I don't like to force directory structures onto others if I can avoid it.

I also think file extension should not be the main way to identify template files.

I think it would be reasonable to assume that a user can include AWSTemplateFormatVersion as a top-level key without the linter's help. Then the linter could easily identify any file with that key as a CloudFormation template.

[PatMyron]

Today any passed in file will be linted

Would like for this to continue to be at least the default

---

Similar discussions: aws-cloudformation/cfn-lint-visual-studio-code#99, aws/aws-toolkit-jetbrains#1715 (comment), https://github.com/github/super-linter/pull/231#discussion_r445708695, mwpearce/vscode-cfn-nag#6, joenye/coc-cfn-lint#3 (comment), #2497

[iainelder]

Request is to add a parameter to cfn-lint that will validate that a YAML/JSON template is a CloudFormation template before linting it.

I need help understanding the use case here.

Linting is validation. If the linter finds a syntax error, is it still a CloudFormation template?

How would you determine the extra parameter value for an arbitrary YAML/JSON file? The best way I can think of is by including it with the template itself as a file extension. cfn-lint can't enforce that, though, because the documentation says any file extension may be used. (I've suggested that a standard file extension be defined to enable this use case.)

I think it would be reasonable to assume that a user can include AWSTemplateFormatVersion as a top-level key without the linter's help. Then the linter could easily identify any file with that key as a CloudFormation template.

I consider it bad form to exclude it, but the according to the template anatomy the AWSTemplateFormatVersion key is optional.

The only required top-level key is Resources.

So this is a valid template:

Resources:
  Placeholder:
    Type: AWS::CloudFormation::WaitConditionHandle

So I think the best cfn-lint could do is emit a warning that the temple doesn't declare a version. As of 0.58.0, it doesn't do that.

[kddejong]

For reference this is the logic for how we do this in the vscode plugin:
https://github.com/aws-cloudformation/cfn-lint-visual-studio-code/blob/19f8b57282ad3ce04be37002bb930db438fca186/server/src/handlers/helpers.ts#L3-L21