Generate schema for v2 manifest

[itowlson]

Attempts #930.

This is for discussion right now. Some questions:

• Does this provide enough value to invest further time making it wholesome? E.g. trigger properties are not autosuggested (but they are validated). You can test the current output by installing Even Better TOML or Taplo and adding the #:schema https://gist.githubusercontent.com/itowlson/080922335ea080a185b77a17b9f1eb03/raw/3c24973fbeec3f3c78a1adc34284c235eba6df23/manifest.v2.triggy.json at the top of a spin.toml file.
• Which triggers should we bake in schemas for? I've done HTTP and Redis, but should we do cron, command, MQTT, SQS, etc. too? (Currently they are not validated but do not cause an error either.)
• How do we want to expose generation? For now I have it as a spin schema command but there's no reason anyone except people updating the manifest format should ever need to run it.
• How do we want to publish/distribute the schema? E.g. asset URL in a GH release, S3 bucket, VS Code extension, BitTorrent... Even Better TOML is happy with HTTP URLs via the #:schema directive, which we could add to templates.

If we decide to press ahead, the main remaining work is:

• Agree design and review implementation
• Update the descriptions/doc comments (which are currently examples rather than explanations)
• Implement publishing / distribution.

Docs are probably a few hours, and I can do them; distribution would depend on how we want to do it.

[karthik2804]

I like adding them to templates, can we add multiple directives and do they need to be at the top?

[lann]

Given that schema is linked to Spin version I suggest adding it as a release artifact, with the latest then naturally available under the canary pre-release e.g. https://github.com/fermyon/spin/releases/download/canary/maniest-schema-or-whatever.json

[itowlson]

@karthik2804 I don't know about multiple directives - I'm not sure what it would mean to specify multiple schemas for a file - can you elaborate? (ETA: oh are you thinking about directives for non-Taplo based tools? Yeah that could get messy if we have to add more than one.)

@lann agree, GH release asset seems easiest if we are comfortable with that

[karthik2804]

I was wondering if we could have multiple schemes injected by each of the template for the trigger such that the entire thing can be validated.

[itowlson]

I don't believe so. I think you'd need something dynamic to inject a field and schema reference for each trigger in the manifest. Or you'd need to select out a range and apply a subschema to that. (You can't attempt to validate the whole document against the subschemata.) At that point, as far as I know, you're drifting beyond what JSON Schema can do and into a full-blown language server.

[karthik2804]

Looking at their docs, there i no support for multiple definitions in the same doc https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive

[itowlson]

Rebased and updated to be a subcommand of the maintenance command we introduced for generating the CLI reference.

[itowlson]

Added release actions to include the schema JSON as part of GH releases. Tested by running in my fork (albeit a subset) - https://github.com/itowlson/spin/actions/runs/14369671054, https://github.com/itowlson/spin/releases/tag/canary) and that seemed okay.