-
Notifications
You must be signed in to change notification settings - Fork 39
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
Log warning when validating a spec against the wrong core schema versions #800
base: main
Are you sure you want to change the base?
Conversation
return new Ajv2020({ | ||
strict: strictType, allErrors: true, loadSchema: async (uri) => { | ||
try { | ||
// validate schema version | ||
checkCoreSchemaVersion(uri, bundledSchemaVersion, debug); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would this work if organisations want to extend the core calm schema but add their own spectral rules for their extensions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you mean if there is effectively a second set of core schemas - the extensions offered by an org - and I guess they would need versioning too?
I guess what I have here is a pretty narrow definition of a 'core schema'.
The reason we embarked on this was that Jim was doing a validate and getting a ton of weird errors because he was using something still pointing at the first release.
What would you say to instead having it just log a warning if you do validation against a spec not found/registered in the schema directory, instead of all this weirdness with 'core schemas'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would make a lot more sense to me. One scenario I was also concerned about (although more a future roadmap end state ) is if I am referencing someone else's CALM spec for node information do I care if its not on the same version of core version anyways. I'm not sure we would want to mandate it, but also not sure what the implications would be on our current tooling. It's kind of why on this comment I was indicating that maybe the tooling goes via a defined model but then that also implies every piece of tooling is extendable or its extendable by folks supplying the necessary "my calm schema -> tooling model" interpreters as part of the cli setup.
a787647
to
f655084
Compare
Initial stab at #314
This looks at the bundled files and then intercepts any load to look at the URL. It's quite crude, but wanted to get an initial PR up to see people's thoughts.