feat: Add script for yaml validation with kubeval

[mimotej]

Signed-off-by: Michal Drla mdrla@redhat.com

Related Issues and Dependencies

…

This introduces a breaking change

• Yes
• No

This Pull Request implements

This PR adds script which can be used in CI to validate YAML manifests using kubeval.
part of: https://github.com/operate-first/SRE/issues/107

Description

[larsks]

I was looking at https://github.com/mimotej/schema-store/tree/add-json-schemas-crds; you'll want to generate the --strict schemas as well -- without those, you won't be able to catch extraneous attributes and mis-spellings, because the non-strict schemas permit arbitrary attributes.

[mimotej]

I was looking at https://github.com/mimotej/schema-store/tree/add-json-schemas-crds; you'll want to generate the --strict schemas as well -- without those, you won't be able to catch extraneous attributes and mis-spellings, because the non-strict schemas permit arbitrary attributes.

@larsks Good idea didn't think about that 👍. The question that only comes to my mind about this is: Should we keep both non-strict and strict schemas in this repository? Because I feel we wouldn't have currently any use for weaker schemas which let slip more error through the checks...

I have updated both script and schema-store repository PR to contain only strict variant of schemas.

[larsks]

The question that only comes to my mind about this is: Should we keep both non-strict and strict schemas in this repository?

I don't see much use for the relaxed schemas in this context, and we can always add them in the future if we decide we have a use case that requires them. Having the strict schemas only right now seems fine.

[mimotej]

/hold
Let's wait till operate-first/schema-store#1 will get merged

[HumairAK]

As a fan of having to wait less time for ci .... any particular reason why we don't just make this part of the kustomize build ci check? the script is nearly identical, you can just just run both checks and if either yields and error the script fails and errexits.

[mimotej]

As a fan of having to wait less time for ci .... any particular reason why we don't just make this part of the kustomize build ci check? the script is nearly identical, you can just just run both checks and if either yields and error the script fails and errexits.

@HumairAK I don't feel like it is gonna take much longer to run it. kustomize build is prerequisite for manifest validation, but I would like more to see when I create PR, if the kustomize build failed or manifest validation failed and I don't want to immediately go looking in the logs. Upside of two scripts is that kustomize build check will be seperate and you can immediately tell what part of CI failed.

[mimotej]

/Unhold
Schemas were merged, so I have changed path to operate-first repository and it can be now merged.

[HumairAK]

/lgtm
/approve

[sesheta]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: HumairAK, larsks

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [HumairAK]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment