Renamed docker-compose YAML files use incorrect schema despite file association

[rcdailey]

Describe the bug

I have a Docker Compose YAML file with the following name:

docker-compose.test.yml

It has the following contents:

services:
  test:
    image: postman/newman:alpine
    build: context
    networks: [my_network]
    depends_on: [deployment]
    environment:
      - app_url=deployment:80
    volumes:
      - ./postman:/etc/newman:ro
    command: >-
      run my.postman_collection.json --reporters junit,cli

I noticed that there was a red-squiggly under services. When hovering over that, it said it was using prometheus.rules.test.json as the schema. So I went to my workspace settings.json and added this:

"files.associations": {
  "docker-compose*.yml": "dockercompose",
}

After reloading VS Code, I noticed that the red-squiggly was still there. Apparently this file association isn't forcing the correct schema to be used, even though Language Mode is clearly set to dockercompose.

After googling some more, I found that this fixes the issue:

"yaml.schemas": {
  "https://raw.githubusercontent.com/compose-spec/compose-spec/master/schema/compose-spec.json": "docker-compose*.yml"
},

Expected Behavior

My expectation is that the docker compose schema is used when language mode is set to dockercompose via files.associations setting in VS Code. I should not have to set the JSON schema explicitly.

Environment

Windows 10

[gorkem]

vscode-yaml actually has no special knowledge of docker-compose schema. It queries the schema store, and if there is a filematch that matches the currently open file, it uses the schema. That is why docker-compose.test.yml is mapped to prometheus.rules.test.json because the filematch rule on the schema store for prometheus.rules.test.json includes *.test.yml. As you found out, the way to fix the broken schema mapping is to explicitly map it on the settings (or with the modeline). Unfortunately, there is no way for us to map language modes to schemas, as such information is not centrally available. Closing as I can not see an easy way to improve.

[rcdailey]

Thanks for the response. I appreciate the info. I think the salient point in your last reply is the remark about there being no language modes to schema mappings. I might be under a false premise here, but I had a different experience with azure pipelines language mode configuration.

When I assigned **/ci/*.yml to files.associations and mapped it to Azure Pipelines language, all of the YAML files in that directory used the proper language mode and schema. I'm not sure if another extension was at play here, but without a clear understanding of what is working underneath, I simply assumed this was just a matter of extensions properly using files.associations.

Can you recommend the "proper" solution here? Would it be making a change to the schema store so that more patterns are matched somehow?

[gorkem]

vscode-yaml does not get notified of the file.associations for Azure Pipelines. It only gets activated for yaml and for legacy reasons dockercompose. Once activated, it tries to map a schema to the file using modeline, settings or the schema store API and provide its functionality.

vscode-yaml provides generic YAML support. There are 100s of schemas, and there is no central database/API that vscode-yaml can query to map a file association to a schema. In your Azure Pipelines case, I guess another extension is activated, which maps the schema through the extension API that vscode-yaml exposes.

vscode-yaml provides modeline, and settings to remedy this kind of situation. I suppose by "proper" solution you mean better schema store mapping. It would help if schema store API could provide more guidance if multiple patterns match. In the past, we have discussed a ranking mechanism for pattern matching but it gets complicated with directory patterns vs file patterns.