The "any" definition in the schema does not allow for `number`

The parameters in a template pipeline have a field, default, defined as "any".

"any" can be seen here: https://github.com/microsoft/azure-pipelines-vscode/blob/2e9781b705725387964e1931d9f52ae455746ca1/service-schema.json#L30-L46

It does not include numeric types. The following pipeline therefore fails validation:

parameters:
- name: vals
  default: [1, 2]
jobs:
- ${{ each val in parameter.vals }}:
  - job: foo
    steps:
    - bash: echo ${{ val }}

My understanding is that the above is valid, and that these values will be coerced to strings appropriately.

[50Wliu]

Is that location publicly available?

Nope (most likely for compliance reasons even if there’s nothing stored in it).

Better yet, can you ask the Azure Pipelines developers provide the base schema from a URL where we could GET it and list it in SchemaStore, to cut out the middleman?

This would be great! I’ll defer to @golubev-ivan on this.

I hope you can understand my distaste for mucking around in a support forum when I’m trying to report a bug.

I understand, it’s not very clear that this repository doesn’t own the schema. That’s something we can do better at clarifying. What makes it even trickier is that parts of the schema (builtin tasks at https://github.com/microsoft/azure-pipelines-tasks) are controllable.

This is getting into the weeds, but “accurate-yaml-validation” more-or-less covers three areas:

• Validation issues with the “core” schema (non-tasks) are out of our control, but the standard has sort of been to keep them open to reduce the number of duplicate issues we get. Moving forward I think the best course of action is still to keep them open, but also to file Developer Community tickets.
• Validation issues with tasks are also kept open, and we try to be good at upstreaming PRs to azure-pipelines-tasks to fix those, then closing the issue once they’re ingested into the schema endpoint.
• Validating correctness beyond the schema, such as template expressions, unique stage names, or only using runtime variables when allowed. And technically those issues belong in azure-pipelines-language-server, but again we’re treating this repository as the landing pad because they’re so tightly coupled.

Essentially, it boils down to “this repository is an aggregator of validation-related issues for visibility. We can answer questions, but if you’re looking for something to be fixed, that ultimately needs to happen elsewhere”, elsewhere being Developer Community/azure-pipelines-tasks/azure-pipelines-language-server.

[mr-dokara]

Hello @sirosen, I’m closing this ticket, since we can’t help you with issues that are related to the schema, our team doesn’t support Azure DevOps YAML schema. Extension in fact is the same consumer of ADO schema as you and all the questions related to schema outside our ownership.