You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This relates to "strict-mode" rule introduced in recent #374 PR.
The rule should also trigger for misspelled (or just gibberish) apiVersion values. However, for some resources it does not. This is because we pick schema for some kinds based only on kind value (and cluster version indirectly) totally ignoring provided apiVersion.
for a cluster version, e.g. 1.26.0 where apps/v1beta1 was removed and apps/v1 is expected, this whole schema will be validated as apps/v1. Not sure how much difference it would make though. And also now we have deprecation rules which can help with that.
So either it is intended behavior or we should add apiVersion value for consideration here. @WitoDelnat and thoughts on this?
The text was updated successfully, but these errors were encountered:
This relates to "strict-mode" rule introduced in recent #374 PR.
The rule should also trigger for misspelled (or just gibberish)
apiVersion
values. However, for some resources it does not. This is because we pick schema for some kinds based only onkind
value (and cluster version indirectly) totally ignoring providedapiVersion
.This is the code responsible for this behavior -
monokle-core/packages/validation/src/validators/kubernetes-schema/resourcePrefixMap.ts
Lines 3 to 37 in 1c90fe2
This also means that having a schema like:
for a cluster version, e.g.
1.26.0
whereapps/v1beta1
was removed andapps/v1
is expected, this whole schema will be validated asapps/v1
. Not sure how much difference it would make though. And also now we have deprecation rules which can help with that.So either it is intended behavior or we should add
apiVersion
value for consideration here. @WitoDelnat and thoughts on this?The text was updated successfully, but these errors were encountered: