schema inputs should prefer specific types instead of general strings

[jtmoon79]

Problem

This Azure Pipeline YAML code, validated against service-schema.json 97f39ff, runs just fine in Azure Devops (greatly simplified for sake of clarity):

# yaml-language-server: $schema=https://raw.githubusercontent.com/microsoft/azure-pipelines-vscode/97f39ff988232860b35556dde725d448151ec5a0/service-schema.json
trigger:
  batch: true
pr: none
stages:
- stage: stage1
  jobs:
  - job: job1
    timeoutInMinutes: 20
    condition: false
    steps:
    - script: echo "hello"

So it runs okay, yet the 20 and true and false are red underlined with hover errors

Incorrect type. Expected "string". yaml-schema: Pipeline schema

The fix is to make the inputs into strings:

# yaml-language-server: $schema=https://raw.githubusercontent.com/microsoft/azure-pipelines-vscode/97f39ff988232860b35556dde725d448151ec5a0/service-schema.json
trigger:
  batch: "true"
pr: none
stages:
- stage: stage1
  jobs:
  - job: job1
    timeoutInMinutes: "20"
    condition: "false"
    steps:
    - script: echo "hello"

However, now the following non-sense YAML values is also considered valid (no hover errors):

# yaml-language-server: $schema=https://raw.githubusercontent.com/microsoft/azure-pipelines-vscode/97f39ff988232860b35556dde725d448151ec5a0/service-schema.json
trigger:
  batch: "FOO"
pr: none
stages:
- stage: stage1
  jobs:
  - job: job1
    timeoutInMinutes: "BAR"
    condition: "!?!?!?!?!?!"
    steps:
    - script: echo "hello"

Solution

It's nice to use raw numbers, booleans, etc. for inputs where such types are expected. Then the user is given more accurate feedback about expected values for various inputs.

Also, in VS Code, they are visually different than plain strings, which is nice.

[vmapetr]

Hi, @jtmoon79 thanks for reporting!
We are working on more prioritized issues at the moment but will get back to this one soon.

[winstliu]

Huh, I can't reproduce this @jtmoon79.

Does the issue still repro if you remove that yaml-language-server comment? It seems significant but I don't recall us keying on that anywhere, so I wonder if another extension you have installed is overriding our schema validation somehow.

[FrancescElies]

I saw the same when using yaml-language-server, in this case isn't yaml-language-server rightfully complaining?

In service-schema.json timeoutinminutes is defined as non empty string but what we wrote is a number which is also accepted but not explicitely stated in the schema.

            "timeoutInMinutes": {
              "description": "Time to wait for this job to complete before the server kills it",
              "$ref": "#/definitions/nonEmptyString"
            },

What am I missing?

[henryiii]

This came up on SchemaStore, as validators like VSCode and others don't recognize numbers as valid for timeoutInMinutes (which is how all the examples in this repo are done, I'd recommend using the examples as input and trying to validate them with the schema file provided). SchemaStore/schemastore#3560