Skip to content
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

Generate schema for v2 manifest #2997

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

itowlson
Copy link
Contributor

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
Copy link
Contributor

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

@lann
Copy link
Collaborator

lann commented Jan 28, 2025

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
Copy link
Contributor Author

itowlson commented Jan 28, 2025

@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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants