-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
versionPattern should be more flexible to allow internal versions #3739
Comments
Hi @robzienert Thank you for raising this one. In this case, it might to be (Required to check): func IsDNS1035Label(value string) []string { However, we need to TBD the right k8s validation and use the same. Your help is very welcome. |
🐛 Align CRD version validation with apiextensions
Hi @robzienert My sincere apologies, I oversight this one. In Kubernetes Custom Resource Definitions (CRDs), Kind names must not include spaces, special characters (e.g., @, #, $, %, &, *), or punctuation marks. They should strictly adhere to CamelCase format, starting with an uppercase letter and not violating the general programming identifier rules (e.g., no starting with numbers, no reserved words). This ensures compatibility with Kubernetes API and client code generation tools. The func IsDNS1035Label(value string) []string { is NOT accurated for this case. The correct one seems to be (from the same file):
Therefore, to close this one we need change the validation like was done in the PR #3742 However, to avoid we introduce and issue we should add more tests in the project to ensure that names like DNS will be allowed to be used. |
@camilamacedo86 is this really a good first issue? I dont see the clear cut implementation to close this issue. |
@Sajiyah-Salat The code for implementation isn’t extensive, which makes it a good-first-issue. |
What broke? What's expected?
The versionPattern enforced by kubebuilder requires all CRD versions to start with a
v
, however this makes usage of an internal version confusing (e.g. creating av0
) where aninternal
or__internal
version would communicate intent more clearly;__internal
is even used within the core Kubernetes codebase.What I'd like to see is the
versionPattern
relaxed to make an allowance for internal versions, something like so:Before:
After:
Doing so would be additive and not break any of the existing uses.
Reproducing this issue
No response
KubeBuilder (CLI) Version
v3.12.0
PROJECT version
No response
Plugin versions
No response
Other versions
No response
Extra Labels
No response
The text was updated successfully, but these errors were encountered: