.gitlab-ci.yml validation errors

[adam-moss]

Hi,

I'm seeing errors in the validation of .gitlab-ci.yml files, specifically anchors, as described in #60.

However, as per #87, this doesn't happen if I rename the file to .yaml where it validates correctly.

Interestingly it does appear to be using the correct schema for validation, just not recognising the anchor is an anchor, and therefore complaining about missing attributes that would otherwise be mandatory.

Thanks.

[JPinkney]

So everything is working correctly when the file is named .yaml but not when it’s named .yml?

[adam-moss]

It appears to, yes

[sebbuku]

Same thing with .circleci/config.yml. It validates if I rename it to config.yaml.

[matalo33]

Confirmed this issue is still present

MacOS
VSCode Version 1.32.3 (1.32.3)
yaml 0.4.0

[jghal]

This is still an issue for me on Amazon Linux 2. But using same version of WSL and YAML plugin on Windows 10 or Windows 10 Remote to WSL Ubuntu 18.04 I don't see the issue.

VSCode 1.38.1
YAML plugin 0.5.3

[robmurtagh]

I'm also seeing this issue:

OS: MacOS Catalina
VSCode Version: 1.39.2
YAML Plugin: 0.5.3

Thanks in advance for reviewing

[adam-moss]

Not sure this is correct?

.gitlab-ci.yml is the correct file name, it is the linter that only works if you rename it to yaml

[faisal6621]

I am also having the same issue:

VSCode: 
  Version: 1.41.1 (system setup)
  Commit: 26076a4de974ead31f97692a0d32f90d735645c0
  Date: 2019-12-18T14:58:56.166Z
  Electron: 6.1.5
  Chrome: 76.0.3809.146
  Node.js: 12.4.0
  V8: 7.6.303.31-electron.0
  OS: Windows_NT x64 10.0.17134
YAML Plugin: 0.6.1

[faisal6621]

Hi @adam-moss,
Are you facing this issue with YAML Anchors? If yes, try extends which is introduced in GitLab 11.3.

cc: @JPinkney

[TBBle]

Those are only substitutes if the YAML Anchors are being used to extend a particular job. It doesn't work for YAML anchors for before_script and after_script for example when used in top-level before_script, rather than per-job before_script.

Once we start using the replacement 'default' job, it's not clear if that will support 'extends' in this way.

[Morriz]

Can we get an update to such a simple problem?

[inostia]

Seeing this specifically when using anchor definitions for gitlab ci scripts, per instructions here: https://docs.gitlab.com/ee/ci/yaml/#yaml-anchors-for-script

I get the same validation issues.

[JPinkney]

Can someone post a yaml file so I can confirm this is working in the pre-release.

Or can someone try with the latest pre-release: https://github.com/redhat-developer/vscode-yaml/releases

[joelmgallant]

@JPinkney - confirmed this behavior can be reproduced on 0.7.2 release.

[JPinkney]

@joelmgallant If it is not working correctly can you post your YAML so I can diagnose the issue

[joelmgallant]

@JPinkney - of course, thanks for investigating!

Here's a minimal reproduction case:

image: a-docker-image

stages:
  - merge-create

# Should be valid, highlighted as incorrect type error
.do-anchor-tasks: &do-anchor-tasks
- ls -lah

merge-create-task:
  stage: merge-create
  when: manual
  script:
    - *do-anchor-tasks

Changing this file to .yaml instead of .yml highlights as expected.

[laymonage]

This issue also raises Property << is not allowed. when using merge keys. Changing the extension to .yaml "fixes" it but we need the file name to be .gitlab-ci.yml.

[JPinkney]

@laymonage Please post the yaml causing this issue and what version of vscode-yaml you are using

[laymonage]

@laymonage Please post the yaml causing this issue and what version of vscode-yaml you are using

Here's an example:

image: python:3.6

stages:
  - test

.disable_dev: &disable_dev
  except:
    - dev@user/repo

.cache_test: &cache_test
  <<: *disable_dev
  stage: test
  cache:
    key: test
    paths:
      - .cache/test

unittest:
  <<: *cache_test
  stage: test
  script:
    - echo "Hello, world!"

Merge key on <<: *disable_dev will throw Property << is not allowed. despite it's valid. I'm using the latest version (0.9.1) of vscode-yaml on Code-OSS 1.47.3.

[OutOfFocus4]

I am also having this issue in a Django project.

Visual Studio Code Information:
Version: 1.48.2
Commit: a0479759d6e9ea56afa657e454193f72aef85bd0
Date: 2020-08-25T10:09:08.021Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.6.0

Using version 0.10.1 of the YAML extension.

Here is part of my .gitlab-ci.yml:

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"

cache:
  key: "$CI_PROJECT_ID"
  paths:
    - .cache/pip
    - venv/

.Test: &test-template
  stage: test
  only:
    - master

.django-test: &django-template
  <<: *test-template  # Property << is not allowed.
  before_script:
    - echo "Not relevant"

.browser: &browser-template
  <<: *test-template  # Property << is not allowed.
  before_script:
    - echo "Not relevant"

# Other stuff below this validates

[Matthew-Benson]

The extensions page says it uses schema store to automatically try to match up the schema using the file name you're editing.

Having a look at the gitlab-ci schema on the schema store here it seems like this just doesn't match up with the actual schema gitlab expects.

Changing the file to .yaml makes this lookup not match/not happen.

You can change these settings in vscode in your settings.json:

"yaml.schemas": {
    "http://json.schemastore.org/composer": ["/*"],
    "file:///home/johnd/some-schema.json": ["some.yaml"],
    "../relative/path/schema.json": ["/config*.yaml"],
    "/Users/johnd/some-schema.json": ["some.yaml"],
}

There are some open issues on gitlab for them to host their own json schema for gitlab-ci files. Basically what's out there just gets outdated and gitlab has to make pull requests if they change the schema and the whole thing might just be too slow.

Sorry if that's not very helpful but that's about all I could come up with trying to solve the issue.

If you had a valid schema file for the gitlab-ci file (which maybe you could find in a PR over at the json store repo) you could put something in like:

    "file:///home/johnd/gitlab-schema.json": [".gitlab-ci.yml"],

But I can't find a better schema file myself.

[gorkem]

I can no longer reproduce the issues defined on this issue. I suspect that they were fixed when we switched to the new parser. Closing this one please file new issues if there are still issues persisting.