-
Notifications
You must be signed in to change notification settings - Fork 84
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
crdjsonschema action now creates a all.json
schema to validate any Flux2 resource via a single schema
#744
Conversation
The main use case for the schemas is to enable validation in CI. Would this break kubeconform and the script used by almost all Flux users? https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/scripts/validate.sh Can you please test the resulting JSONs with the script above and post the result here? |
TL;DR; No impact on
Just verified (and also tested locally) but we are totally good here! The presence of Finally, I was just working on actually using this during development (linting at development time) and it really does NOT make any sense to include something like below. Especially, because you might have other CRDs that you want to validate in the future. So best thing is to document this somewhere (no clue where...) and let end users use this however they want. {
"oneOf": [
{ "$ref": "https://raw.githubusercontent.com/fluxcd-community/flux2-schemas/main/all.json" },
{
"$ref": "https://raw.githubusercontent.com/yannh/kubernetes-json-schema/master/master-standalone-strict/all.json"
}
]
} For completeness, I tested the impact of this PR on Double checked if things are really working as expected by modifying HelmRelease schema kind to type number to see if it would fail. When "breaking" |
@kevinvalk please rebase with upstream main and force push, this PR should have a single commit. Thanks |
581b027
to
b6835b1
Compare
Done (after a bit of a mess...) |
…against any of Flux2 CRDTs Signed-off-by: Kevin Valk <kevin@valk.email>
@kevinvalk I think the |
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.
LGTM
Thanks @kevinvalk 🥇
This enables JSON schema extensions to validate Flux2 resources by pointing to the
all.json
file. Background: fluxcd-community/flux2-schemas#23I dropped some old Python2 compatibility code (
iteritems
) and I am using dataclasses (minimum Python version 3.7). I think this is not a problem because it is being run through the Dockerfile which is usingpython:3-alpine
anyways.Example usage in VSCode
When using the YAML extension you could use this new
all.json
schema like so (if this PR is merged and the flux2-schemas repo is updated):.vscode/settings.json
This would net you nice validation in (for example) VSCode for Flux2 resources:
Schema validations are based on glob patterns and in the case of YAML for VSCode will not fallback when providing multiple root schemas. This means that in a typical GitOps repository (in which you mix Flux and Kubernetes resources) you either validate Flux resources OR Kubernetes resources. This sucks, but it can be fixed by stitching together Kubernetes schemas and flux schemas like so.
.vscode/kubernetes.json
I experimented with including this kubernetes.json schema file as well, but that does not feel right and it probably makes more sense to leave this configuration step up to an end user. Especially because different JSON schema validation plugins will handle fallbacks etc differently.
.vscode/settings.json
Setting
"kubernetes"
to empty string is required as the YAML plugin for VSCode always tries to match Kubernetes schema and if you do not do this you will get "Matches multiple schemas when only one must validate" errors.