-
Notifications
You must be signed in to change notification settings - Fork 105
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
Incorrect type. Expected "string | array | object(Azure Pipelines)" when using number parameter #513
Comments
Hi @james-woodbridge, thank you for reporting the issue, we will take a look at it in order of priority |
@james-woodbridge, I can't reproduce this behavior. parameters:
- name: timeoutInMinutes
type: number
default: 60
jobs:
- name: Run a one-line script
script: echo Hello, world! This YAML passed as valid. |
Hi @james-woodbridge, |
Hi @kirill-ivlev and @ivanduplenskikh I am still seeing this issue. My parameters block looks like this:
and I'm using v1.208.0 of the Azure Pipelines extension and v1.78.2 of vscode. |
@james-woodbridge, are you using a custom service schema in your project workspace? |
Hey, I'm facing the same issue, but not in the parameters.
|
Seeing this on:
|
Okay, I think I know what's going on here. Please make sure that the file language is set to "Azure Pipelines", not YAML. My hunch is that if you also have the YAML extension installed (and have the language set to YAML), you'll get the YAML extension's schema detection which doesn't work because the Pipelines schema is a little non-standard. (Which is also, incidentally, why we needed to fork the YAML language server.) I'll close this for now but please let me know if you continue to see this even when the language is set correctly. |
Current behaviour
Pipeline validation raises an error stating
Incorrect type. Expected "string | array | object(Azure Pipelines)"
when using a parameter with the number type and a default value. For example:Expected behavior
Pipeline validation does not raise an error for a number parameter having a numerical default.
Suggestion
Potentially resolved by adding
"type": "number"
to the list of types in the#definitions/any/anyOf
section of the schemaThe text was updated successfully, but these errors were encountered: