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

Log warning when validating a spec against the wrong core schema versions #800

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

willosborne
Copy link
Member

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.

return new Ajv2020({
strict: strictType, allErrors: true, loadSchema: async (uri) => {
try {
// validate schema version
checkCoreSchemaVersion(uri, bundledSchemaVersion, debug);
Copy link
Member

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?

Copy link
Member Author

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'?

Copy link
Member

@LeighFinegold LeighFinegold Jan 17, 2025

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.

@willosborne willosborne force-pushed the detect-wrong-schema-version branch from a787647 to f655084 Compare January 17, 2025 14:17
@github-actions github-actions bot removed the config label Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants