Schema validation errors for dynamic job name within azure pipeline

[robertaves]

Problem:
When using expressions for job names we get a Schema validation error.

parameters:
  - name: name
    type: string

stages:
  - stage: aws
    displayName: AWS
    jobs:
      - job: "${{ parameters.name }}"

Error:

Setup:

repos:
    - repo: https://github.com/python-jsonschema/check-jsonschema
      rev: 0.18.4
      hooks:
        - id: check-azure-pipelines
          files: '^.azure/.*\.yml'

Note this also errors out in the Azure Server Lang plugin as well as it can't validate the schema

[sirosen]

I don't know that there's anything the checker can do in this case out of the box. The azure pipelines schema doesn't really describe what those files can contain.

I don't want that to be my final answer -- even weak validation is worth something -- but it is my starting point.

I'm thinking about how to work around this without trying to really implement their expression language (that seems very fraught to me). What if I offered an option to replace strings prior to validation, such that you could write in your config

  add_args: ["--replace-string", "${{ parameters.name }}", "dummy-job-name"]

?

Would that be sufficient and interesting to you as a user?

I might not want to make it a CLI option, perhaps config instead, but that would be the idea of it.
Or it might be nicer to let you specify jsonpath to the value which needs replacement.

[robertaves]

Json path might be cleaner via a config as our pipelines are utilizing the templated job names quite a bit.. Some come from variables, some come from parameters so replace-string may be hard to scale. If we could some how ignore values in certain json paths it might be more flexible and scalable.

[sirosen]

If we could some how ignore values in certain json paths it might be more flexible and scalable.

I wish we could. I agree that it would work better from a user-perspective: you get an error from the linting and you effectively say "ignore that error".
Unfortunately, I think that would require modifying the schema, and there's no reliable way to do that with nested structures like oneOf.

I'll try to make time soon to work on some kind of replacer config, since that's the best workaround I can come up with.