-
-
Notifications
You must be signed in to change notification settings - Fork 581
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
jsonschema: now available as a dockerized tool for CI / CD #640
Comments
Thanks! Will have a look. |
Still having a look, thanks again for this, but I had a question about the warning you put there:
I assume this is related to #641, but what's there to warn about there? The metaschema(s) are non-normative -- what stumbling block exists for someone that the warning is trying to point out? Or put another way, what user would want to do what you mention there (use the "official" meta schema rather than the vendored one)? |
True, official JSON schema files are not normative. But they are a kind of quasi-standard. Most tools use the official JSON schema files. It is a surprice if one tool is using not the official schema files (e.g. a patched one). Documentation should warn about such things, that break the Principle of Least Surprise. If jsonschema would use the official JSON schema by default, and the patched JSON schema only when requested (e.g. with a I am open for text contributions. BTW: I would love to see a PR for patch No1 and patch No2 to the official JSON schema repo, to let other tools also participate in your findings (improved schema; closer to the specs). |
If the tools you're mentioning are using the official meta schemas and not
applying the behavior dictated by the spec, they have bugs, that's
literally what "non-normative" means.
The principle of least surprise doesn't apply here.
But thanks for clarifying.
…On Sun, Dec 15, 2019, 13:09 christian-weiss ***@***.***> wrote:
True, official JSON schema files are not normative. But they are a kind of
quasi-standard.
Most tools use the official JSON schema files. It is a surprice if one
tool is using not the official schema files (e.g. a patched one).
Documentation should warn about such things, that break the Principle of
Least Surprise. If jsonschema would use the official JSON schema by
default, and the patched JSON schema only when requested (e.g. with a
--use-improved-schema or something similar), then it would not violate
the Principle of Least Surprise.
I am open for text contributions.
BTW: I would love to see a PR for patch No1 and patch No2 to the official
JSON schema repo, to let other tools also participate in your findings
(improved schema; closer to the specs).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#640>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACQQXUCHMW7KNWT6XNHUJLQYYT7PANCNFSM4JXNHFVA>
.
|
Had a quick look here -- thanks again for putting this together. Great to have an image pushed. I think for now I'll wait to see if there's sufficient demand for this (via people pulling the image) -- if enough people want it I'll ping you about it, but for now seems great to have someone maintaining it already. Thanks! |
19947eaa1 test: unevaluatedProperties not affected by propertyNames 829270631 Check that large integers are multiples of small multipleOf b59543f6e Merge pull request #647 from santhosh-tekuri/ref-start-slash 6e5d45d71 Merge pull request #646 from santhosh-tekuri/vocab-optional 0311dfda0 Merge pull request #651 from santhosh-tekuri/dynamicref-without-anchor 4503eeaf4 test: A $dynamicRef without anchor in fragment behaves identical to $ref 39af4c1ba test: $ref with absolute-path-reference 880c9933b test/vocabulary: ignore unrecognized optional vocabulary fd80307ff Merge pull request #642 from santhosh-tekuri/time-2digit a76ae650d Merge pull request #645 from json-schema-org/gregsdennis/add-vocab-tests-link 0e2b4eefd Merge pull request #643 from 0xSudarshan/main 2b78ccfc4 slight tweaking to wording 8716c4054 add link for vocab test suite to readme c49ba5445 Fix an incorrect $schema identifier. f0e5ce71e Added test for schema-items alongside "ignored" additionalItems 76dae88ab Merge pull request #640 from santhosh-tekuri/refRemote-anchor cb82e237c Merge pull request #641 from json-schema-org/gregsdennis/unevaluated-not-draft-next e4afd233a test/format: hour, min, sec must be two digits 7efd51313 fix unevaluatedProperties/not tests for draft-next e39c6ea6a test/refRemote: anchor within remote ref bf51b32fb Merge pull request #639 from json-schema-org/additionalItems-unevaluatedItems 52160b368 Add a test for 2019's interaction between additional/unevaluatedItems 69a09a339 Fixed tests for annotation collection inside not. e4e1a220b Draft7 if/then/else ref tests need to be wrapped in an allOf. f5bd2f6c3 Merge pull request #632 from json-schema-org/ether/annotations-inside-not 626b433e5 test that annations are collected inside a "not" git-subtree-dir: json git-subtree-split: 19947eaa1289168a49edd21bb7a8aa2098069ae0
Hi Julian,
once again i want to thank you for this great validator.
To enable the crowd to easily use jsonschema in CI / CD pipelines i implemented an automated build and release of a docker image, which is available at: https://hub.docker.com/r/freifunkhamm/jsonschema. This docker image is automatically scanned for security vulnerabilities with trivy.
You are warm welcomed to join the release process. If your are interested in it i can grant you direct permissions at https://github.com/Freifunk-Hamm/docker_jsonschema. Just ping me.
Release cycle is very simple:
a) change Dockerfile (new version number)
b) commit and tag commit with version number
c) push
(we use sticky version numbers to have the same result on subsequent build re-runs of the same commit)
Feel free to link it in your github repo / project website.
Alternative:
If you want to create your own namespace/organisation at DockerHub feel free to grap my code and enable automation in your git repo.
The text was updated successfully, but these errors were encountered: