Open dvonessen opened 7 years ago
I've run into this myself. I tried adding a custom schema in the workspace setting (which to be fair, I'm not sure is correct, and now can't remember where I nicked it from).
schema (cloudformation.schema.json):
{
"mapping": [
"Base64"
],
"scalar": [
"Ref",
"Sub",
"GetAZs",
"GetAtt",
"ImportValue",
"Condition"
],
"sequence": [
"And",
"Equals",
"GetAtt",
"If",
"FindInMap",
"Join",
"Not",
"Or",
"Select",
"Sub",
"Split"
]
}
workspace settings:
{
"json.schemas": [
{
"fileMatch": [
"*.cf.yml"
],
"url": "./cloudformation.schema.json"
}
]
}
I'm not certain it's being picked up, and the error highlighting certainly doesn't disappear.
@pms1969 I really don't think that is a JSON Schema
@dthielking In YAML, !Join
, !FindInMap
, and !Ref
are all tags and are used to convey type information.
YAML tags are used to associate meta information with each node. In particular, each tag must specify the expected node kind (scalar, sequence, or mapping).
Since the underling parser does not know what these tags are, it does not know what kind of node they represent to be able to continue with parsing. I have not tested it, but I think the parser we use supports teaching it new types, but that would still leave the issue on how to communicate that information to the parser. (If that is all figured out, then the question becomes what sort of schema you are looking to apply here; ex. the tag-names relevant?)
is it fair to assume that all !Ref
like tags are simply text replacements for values that were defined earlier or elsewhere?
If so, the parser could read a yaml and store the Parameters
"table" (Im looking at the specific case of a Serverless definition but it can be more generalized or parameterized) internally, replacing the !<tag>
with a type equivalent, for example:
Parameters:
AppName:
Type: String
Description: The name of the application
Resources:
MyFunction:
SomeTag: !Ref AppName
In practice "AppName" would be defined by a parameter in a cli call or read from a configuration file or just taken from somewhere, but maybe all the parser needs is to replace !Ref AppName
with a value of the type defined in the Parameters section:
Parameters:
AppName:
Type: String
Description: The name of the application
Resources:
MyFunction:
SomeTag: "Some random string"
The original schema doc I had was https://d1742qcu2c1ncx.cloudfront.net/latest/gzip/CloudFormationResourceSpecification.json
Is that more like it??? very naive about json schemas.
Actually, this seems what I'm looking for http://fungusakafungus.github.io/cloudformation-jsonschema/v0.4/schema.json
But even that doesn't work. Ho hum.
I'm having the same problem with Ansible variable files, which can contain the tag !vault
. No type information is possible there because the value is encrypted data. I'd just like VS Code to not red-squiggle the whole rest of my file.
I opened this issue incorrectly in VSCode issues. But same problem.
As another use case, we use import-yaml-loader
in our project, which passes a custom type to js-yaml
that defines a !import
tag allowing us to include other files. TBH, I really don't think I need this plugin to actually parse the includes, since the referenced values will just be treated like strings anyway.
It seems like the way to solve this would be to allow for a js file in the workspace config directory (or the workspace root) that can export an object that gets passed to js-yaml
as the parser options. Is there precedence for anything like this with other vscode extensions?
I'm trying out VSCode, this one is a blocker for me moving from Atom.
Publishing this here in case anybody else stumbles across it. This particular extension has now been replaced by the "YAML Support by Red Hat" extension, which suffers from the same problem out of the box.
There's a reasonably straightforward config workaround for this in that extension:
Taking the list of functions documented at: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html
and checking the readme at: https://github.com/redhat-developer/vscode-yaml
My solution was to add the following settings to my user/project settings:
"yaml.customTags": [ "!FindInMap sequence", "!GetAtt", "!GetAZs", "!ImportValue", "!Join sequence", "!Ref", "!Select sequence", "!Split sequence", "!Sub" ]
Note that while the readme describes the object type capabilities as having an uppercase first letter (Scalar, Sequence, Mapping, Map), I found that this caused the YAML server to crash. Setting it to lower case as above seems to fix the issue.
The approach of @dmakovec is working well. Just added !Equals sequence
there:
"yaml.customTags": [
"!Equals sequence",
"!FindInMap sequence",
"!GetAtt",
"!GetAZs",
"!ImportValue",
"!Join sequence",
"!Ref",
"!Select sequence",
"!Split sequence",
"!Sub"
]
@Zebradil when I add yaml.customTags, i see a message in vscode 'Unknown configuration setting'. Anything i'm missing?
@cheedallarajesh Looks fine. Are you sure you have YAML extension installed? If so, check extension «contributions» page. There should be all configuration settings added by this extension.
Ha!! that's the issue. I could able to add it after installing the extension. Thank you @Zebradil
I did @Zebradil 's fix and everything worked. I did not even need to have the YAML plugin.
I tried @Zebradil solution. It works fine until I do not enable Ansible plugin.
CloudFormation creates the following YAML when converting from JSON to YAML through the Designer. JSON
"EndpointConfigName": {
"Fn::GetAtt": [
"EndpointConfig",
"EndpointConfigName,"
]
}
YAML
EndpointConfigName: !GetAtt
- EndpointConfig
- EndpointConfigName
This will result in a Sequence instead of a Scalar. Although both are possible. !GetAtt EndpointConfig.EndpointConfigName
To allow this as a valid YAML file in VSCode, update @Zebradil's solution with
!GetAtt sequence
Mine looks like this now
"yaml.customTags": [
"!Equals sequence",
"!FindInMap sequence",
"!GetAtt",
"!GetAtt sequence",
"!GetAZs",
"!ImportValue",
"!Join sequence",
"!Ref",
"!Select sequence",
"!Split sequence",
"!Sub"
]
Also worked for me in solving unknown !Ref tag errors in CloudFormation YAML files using linter-js-yaml 1.4.6 by adding the following in config.cson:
"linter-js-yaml":
customTags: [
"!Equals sequence"
"!FindInMap sequence"
"!GetAtt"
"!GetAtt sequence"
"!GetAZs"
"!ImportValue"
"!Join sequence"
"!Ref"
"!Select sequence"
"!Split sequence"
"!Sub"
]
I had to add "!Base64 mapping"
today to the above list. This now makes it:
"yaml.customTags": [
"!Equals sequence",
"!FindInMap sequence",
"!GetAtt",
"!GetAtt sequence",
"!GetAZs",
"!ImportValue",
"!Join sequence",
"!Ref",
"!Select sequence",
"!Split sequence",
"!Sub",
"!Base64 mapping"
]
Hello,
I still have the issue I have the RH extension I have this : in settings ` { "python.linting.pylintEnabled": false, "python.linting.flake8Enabled": true, "python.linting.enabled": true, "cSpell.ignoreWords": [ "nativeretweets", "serverlessrepo" ], "yaml.customTags": [ "!Equals sequence", "!FindInMap sequence", "!GetAtt", "!GetAZs", "!ImportValue", "!Join sequence", "!Ref", "!Select sequence", "!Split sequence", "!Sub" ], "yaml.trace.server": "verbose",
}`
AN I still have this : JS-YAML: unknown tag <!Ref> at line 49, column 37 in the problems ;)
Any clues ?
@Chewbee Ia facing the same error JS-YAML: unknown tag <!encrypted/pkcs1-oaep> at line 8, column 17
when I try to add !encrypted/pkcs1-oaep
, I start to think that there is something else overriding out config and thus producing the same error.
@ssbarnea @Chewbee
I had the same issue, but I disabled Ansible plugin. From what I can see also Cloud Code plugin might cause such issues. They both run yaml server in the background, but ignore yaml.customTags
settings
Hi,
Unfortunately I have some problems to validate yaml documents for AWS CloudFormation. I have following line in my Template:
TemplateURL: !Join ["/", [ !FindInMap [CFNBucket, !Ref "AWS::Region", !Ref "Environment" ], "cfn-generic/s3_single.yaml"]]
Starting with !Join I get following error:
JS-YAML: unknown tag <!Join> at line 37, column 20
Is there a solution to workaround with this, so that I can validate my templates. E.g. CustomTags that are ignored.