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

YAML Anchors and References Break Schema Validation and Suggestions #158

Open
1 of 4 tasks
svrx opened this issue Mar 2, 2021 · 6 comments
Open
1 of 4 tasks

YAML Anchors and References Break Schema Validation and Suggestions #158

svrx opened this issue Mar 2, 2021 · 6 comments

Comments

@svrx
Copy link

svrx commented Mar 2, 2021

Describe the bug

When user anchors or references in CloudFormation YAML files, schemas stops working when anchors/references are used.

Originally chased with redhat.vscode-yaml in redhat-developer/vscode-yaml#425, but became clear the issue was being caused by this extension.

Since CloudFormation supports anchors and references through the aws cloudformation package path, would it make sense to fix the underlying issue?

Expected Behavior

It works as normal.

Current Behavior

Following error keeps repeating as elements are hovered.

Error thrown while requesting schema "Error: end of the stream or a document separator is expected" when calling the registered contributor "cloudformation"

Steps to Reproduce

  1. Add an anchor to any element
...
 Tags: &tags
   - Key: Application
     Value: MyApp
...

Environment

  • Windows
  • Mac
  • Linux
  • other (please specify)
@kddejong
Copy link
Contributor

kddejong commented Mar 4, 2021

having troubles replicating the issue going to have to do some more work to dig deeper on this one.

@kddejong
Copy link
Contributor

kddejong commented Mar 4, 2021

I was able to replicate the only issue I have is that CloudFormation yaml doesn't support aliasing.

@svrx
Copy link
Author

svrx commented Mar 5, 2021

Directly, indeed it doesn't!
Although there are workarounds to make it work through pre-processing.
Such as described here at aws/serverless-application-model#228, through aws cloudformation package or even just through simple parse and render script.

I understand your question, as it isn't directly accepted by the API. Maybe a warning should be generated when anchors or references are detected, if this turn out to be supported.

Question that remains is, should an IDE integration inherit constraints of target system and break or rather support the developer and provide advice?

@sebastian-fredriksson-bernholtz

Maybe this extension could catch the errors and handle them in some way instead of passing them on to the vscode-yaml extension? Or replace the node-yaml-parser? I might have a go at a PR, but not making any promises.

Can you set this extension to only run on specified yaml files?

=== Background ===

I'm having the same problem. However, this also happens in non-cloudformation (bitbucket pipeline) yaml files that DOES support aliasing. I have resorted to disabling/enabling this extension depending on the file I'm working on, but that is more effort than just running cfn-lint manually.

According to redhat-developer/vscode-yaml#425 (comment), they will update to handle errors thrown from contributing extensions, but it doesn't seem like that has been sorted yet.

They also indicate that the error is coming from node-yaml-parser, which doesn't seem to be maintained. Worth replacing with something else?

@PatMyron
Copy link
Contributor

@sebastian-fredriksson-bernholtz could you share your bitbucket pipeline YAML file? Wondering if it's affected by this PR that recognized more CloudFormation templates: #201

@sebastian-fredriksson-bernholtz
Copy link

It seems like the main issue impacting me is that Cloudformation Linter causes vscode-yaml validation to be turned off. I'm not sure that the error indicated by the error messages mentioned in the ticket is the cause of my problem.

=== More information ===

@PatMyron You can find the file attached. However, after looking at that PR, I checked the output and found that it detects that it isn't a Cloudformation file.

I realised that the "yaml.validate" setting is being set to false when the Cloudformation linter is enabled. If I switch it back to true the validation works, despite vscode-yaml still outputting error messages. But it toggles to false again on reload when I have the cfn linter extension enabled. Knowing this makes it much more convenient for me.

Happy to provide any information that can help debug, if you think something still needs to be changed in this extension. Below is a screenshot with the cfn linter output, a screen recording to show what I'm experiencing, and my bitbucket pipeline file.

Screen Shot 2021-11-12 at 00 44 57

Linter.issue.mp4
Bitbucket pipeline file
definitions:
    services:
        docker:
            memory: 3072

    steps:
        - step: &install-build
              name: Install and Build
              script:
                  - make install
                  - make build
              services:
                  - docker
              caches:
                  - docker
              artifacts:
                  - node_modules/**
                  - src/**
                  - packages.json
                  - package-lock.json
                  - jest.config.js
        - step: &lint
              name: Lint
              script:
                  - make lint
              services:
                  - docker
              caches:
                  - docker
        - step: &test
              name: Test
              script:
                  - export NODE_OPTIONS=--max-old-space-size=3072
                  - make test
              services:
                  - docker
              caches:
                  - docker
        - step: &deploy
              name: Deploy
              script:
                  - source set_env.sh
                  - make deploy
              services:
                  - docker
              caches:
                  - docker
        - step:
              &set-environment-variables # Usage: override 'script' and append commands to set variables into set_env.sh. Then source the set_env.sh file in later steps where you want the variable set.
              name: Set set_env.sh artifact
              artifacts:
                  - set_env.sh

pipelines:
    default:
        - step:
              <<: *set-environment-variables
              script:
                  - echo export TARGET_DEPLOYMENT_ENVIRONMENT="staging" >> set_env.sh
        - step: *install-build
        - parallel:
              - step: *lint
              - step: *test
        - step:
              <<: *deploy
              trigger: manual
              deployment: staging
              name: Deploy to Staging (Manual)
    branches:
        staging:
            - step:
                  <<: *set-environment-variables
                  script:
                      - echo export TARGET_DEPLOYMENT_ENVIRONMENT="staging" >> set_env.sh
            - step: *install-build
            - parallel:
                  - step: *lint
                  - step: *test
            - step:
                  <<: *deploy
                  name: Deploy Staging
                  deployment: staging
        uat:
            - step:
                  <<: *set-environment-variables
                  script:
                      - echo export TARGET_DEPLOYMENT_ENVIRONMENT="uat" >> set_env.sh
            - step: *install-build
            - parallel:
                  - step: *lint
                  - step: *test
            - step:
                  <<: *deploy
                  name: Deploy UAT
                  deployment: uat
        preview:
            - step:
                  <<: *set-environment-variables
                  script:
                      - echo export TARGET_DEPLOYMENT_ENVIRONMENT="preview" >> set_env.sh
            - step: *install-build
            - parallel:
                  - step: *lint
                  - step: *test
            - step:
                  <<: *deploy
                  name: Deploy Preview
                  deployment: preview
        prod:
            - step:
                  <<: *set-environment-variables
                  script:
                      - echo export TARGET_DEPLOYMENT_ENVIRONMENT="prod" >> set_env.sh
            - step: *install-build
            - parallel:
                  - step: *lint
                  - step: *test
            - step:
                  <<: *deploy
                  name: Deploy Production
                  deployment: production
                  trigger: manual

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants