OCPEDGE-2084: chore(tools): bump controller-tools with XValidation ordering fix #2658
Conversation
|
Hello @jaypoulz! Some important instructions when contributing to openshift/api: |
📝 WalkthroughWalkthroughEnum validation annotations were moved from some struct fields to their type declarations (ConsoleSampleSourceType) and the per-field enum constraint for RetentionType was removed. Backups CRD schemas consolidated allOf-based enums for 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.5.0)Error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented Comment |
jaypoulz
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@jaypoulz: This pull request references OCPEDGE-2084 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
added
the
size/XXL
|
@jaypoulz: This pull request references OCPEDGE-2084 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
PR Compliance Guide 🔍Below is a summary of compliance checks for this PR:
Compliance status legend🟢 - Fully Compliant🟡 - Partial Compliant 🔴 - Not Compliant ⚪ - Requires Further Human Verification 🏷️ - Compliance label |
|||||||||||||||||||||||
PR Code Suggestions ✨Explore these optional code suggestions:
|
|||||||||||||||||||||||
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In
`@config/v1/tests/infrastructures.config.openshift.io/DyanmicServiceEndpointIBMCloud.yaml`:
- Line 53: The expectedError string for the test case
DyanmicServiceEndpointIBMCloud.yaml contains an extraneous closing square
bracket before the final quote; edit the expectedError value (the YAML key
expectedError) and remove the trailing ']' so the string matches the other
multi-error entries (e.g., the part ending with "url must use https scheme"
should not have a trailing bracket). Ensure the rest of the quoted string
including the multi-error messages and commas remains unchanged.
In `@console/v1/types_console_sample.go`:
- Around line 126-129: The kubebuilder enum marker above the
ConsoleSampleSourceType definition uses the wrong syntax (`Enum:=`) and should
be replaced with the standard form using an equals sign and a JSON-style list of
values; update the marker on the ConsoleSampleSourceType enum to use `Enum=` and
list the allowed values ("GitImport","ContainerImport") in braces so
controller-gen emits proper enum validation.
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml`:
- Around line 472-482: Update the x-kubernetes-validations rules in the
authentication CRD: (1) change the user-info check to reject any user@ in the
scheme+authority portion by using a regex that checks for "scheme://...@", e.g.
negate a match like '^[a-zA-Z][a-zA-Z0-9+.-]*://[^@/]+@', and (2) guard the
url(self) calls in the query and scheme rules by prepending isURL(self) && so
the rules become isURL(self) && url(self).getQuery().size() == 0 and isURL(self)
&& url(self).getScheme() == 'https' so url() is only called on valid URLs;
update the rules in the same x-kubernetes-validations list (the rules
referencing discoveryURL and url(self)) accordingly.
In `@payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml`:
- Around line 76-78: The CEL checks are comparing raw PEM headers against fields
encoded as format: byte (base64), so they never match; fix by either (A)
updating the CEL rules for fulcioCAData, rekorKeyData, caIntermediatesData,
caRootsData, keyData, and publicKey.rekorKeyData to validate the base64-encoded
form (e.g., check for base64 encoding of "-----BEGIN CERTIFICATE-----" or
appropriate header prefix) or (B) change those field schemas to remove format:
byte so the API will carry raw PEM text and then adjust/remove the CEL rules to
match raw PEM headers; pick one approach and apply it consistently for all
listed fields.
♻️ Duplicate comments (3)
config/v1/tests/authentications.config.openshift.io/ExternalOIDC.yaml (2)
745-745: Same index-ordering brittleness applies here.
Please ensure/1is still the intended query rule after reordering.
788-788: Same index-ordering brittleness applies here.
Please ensure/1is still the intended query rule after reordering.openapi/openapi.json (1)
24820-24823: Same enum constraint consideration applies here.This is the same pattern as the earlier
synchronizedAPIfield. If you add an enum constraint there, ensure consistency here as well.
🧹 Nitpick comments (2)
config/v1/tests/authentications.config.openshift.io/ExternalOIDC.yaml (1)
702-702: Guard against brittle index-based JSONPatch removals.Line 702 removes the validation rule at index
/1, which currently corresponds to the "must not have a query" rule. However, this index-based approach is fragile: if validation rules are reordered or new rules are added inconfig/v1/types_authentication.go, this path would target the wrong rule. Consider adding a precedingtestoperation to verify the rule content before removal, making the patch resilient to reordering.Reference: issuerURL validations (current order)
- Index 0:
isURL(self)→ "must be a valid URL"- Index 1:
isURL(self) && url(self).getQuery() == {}→ "must not have a query"- Index 2:
isURL(self) && url(self).getScheme() == 'https'→ "must use the 'https' scheme"- Index 3:
self.find('#(.+)$') == ''→ "must not have a fragment"- Index 4:
self.find('@') == ''→ "must not have user info"openapi/openapi.json (1)
24713-24716: Consider adding enum constraint to match documented valid values.The description states valid values are
"MachineAPI"and"ClusterAPI", but the schema lacks an enum constraint to enforce this. This creates a gap where the API documentation promises stricter validation than the schema actually provides.If the field values should be constrained, consider adding an enum:
"synchronizedAPI": { "description": "synchronizedAPI holds the last stable value of authoritativeAPI...", "type": "string", "enum": ["MachineAPI", "ClusterAPI"] }If this is intentional (e.g., to allow future extensibility or because validation happens elsewhere), please verify.
| - name: VPC | ||
| url: " " | ||
| expectedError: "spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url must use https scheme, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url path must match /v[0,9]+ or /api/v[0,9]+, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": url must be a valid absolute URL]" | ||
| expectedError: "spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": url must be a valid absolute URL, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url path must match /v[0,9]+ or /api/v[0,9]+, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url must use https scheme]" |
There was a problem hiding this comment.
Extraneous ] at the end of the expected error string.
The expectedError string ends with url must use https scheme]" but the trailing ] before the closing quote appears to be a typo. Other multi-error expectedError strings in this file (lines 40, 79, 92) do not include square brackets around the error list.
Proposed fix
- expectedError: "spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": url must be a valid absolute URL, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url path must match /v[0,9]+ or /api/v[0,9]+, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url must use https scheme]"
+ expectedError: "spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": url must be a valid absolute URL, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url path must match /v[0,9]+ or /api/v[0,9]+, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url must use https scheme"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| expectedError: "spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": url must be a valid absolute URL, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url path must match /v[0,9]+ or /api/v[0,9]+, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url must use https scheme]" | |
| expectedError: "spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": url must be a valid absolute URL, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url path must match /v[0,9]+ or /api/v[0,9]+, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url must use https scheme" |
🤖 Prompt for AI Agents
In
`@config/v1/tests/infrastructures.config.openshift.io/DyanmicServiceEndpointIBMCloud.yaml`
at line 53, The expectedError string for the test case
DyanmicServiceEndpointIBMCloud.yaml contains an extraneous closing square
bracket before the final quote; edit the expectedError value (the YAML key
expectedError) and remove the trailing ']' so the string matches the other
multi-error entries (e.g., the part ending with "url must use https scheme"
should not have a trailing bracket). Ensure the rest of the quoted string
including the multi-error messages and commas remains unchanged.
| // ConsoleSampleSourceType is an enumeration of the supported sample types. | ||
| // Unsupported samples types will be ignored in the web console. | ||
| // +kubebuilder:validation:Enum:=GitImport;ContainerImport | ||
| // +kubebuilder:validation:Enum:="GitImport";"ContainerImport" | ||
| // +enum |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, find and read the file to confirm the content
find . -path "*console/v1/types_console_sample.go" -type fRepository: openshift/api
Length of output: 93
🌐 Web query:
controller-tools kubebuilder +enum marker validation:Enum syntax documentation
💡 Result:
Short summary — syntax for the +kubebuilder:validation:Enum marker
-
Basic form: place the marker on the field comment:
// +kubebuilder:validation:Enum=. [1][2] -
Value lists can be written two ways:
- Semicolon-separated simple values (no quotes):
// +kubebuilder:validation:Enum=Wallace;Gromit;Chicken. [1][2] - JSON-style/braced list (use quotes for strings or values with spaces/commas):
// +kubebuilder:validation:Enum={"crackers, Gromit, we forgot the crackers!","not even wensleydale?"}. [1][2]
- Semicolon-separated simple values (no quotes):
-
Notes:
- Marker names are case-sensitive (must be +kubebuilder:validation:Enum). Check generated CRD to confirm output. [4][1]
- Enum applies to the JSON schema generated for the field (controller-gen/controller-tools). See controller-tools markers docs for full details. [3][1]
Sources:
[1] Kubebuilder markers reference (controller-gen marker syntax & examples).
[2] Kubebuilder CRD validation docs (Enum examples).
[3] sigs.k8s.io/controller-tools/pkg/crd/markers (pkg docs).
[4] Practical pitfalls (example of misspelling/case-sensitivity).
🌐 Web query:
kubebuilder validation Enum quoted values semicolon separator controller-gen
💡 Result:
Short answer: controller-gen accepts two forms for +kubebuilder:validation:Enum.
-
Simple single-word values (no spaces/punctuation): semicolon-separated, quotes optional.
Example: // +kubebuilder:validation:Enum=Wallace;Gromit;Chicken. [1][2] -
Values that need quotes (spaces, punctuation, or contain semicolons): use a brace-enclosed, comma-separated quoted list (JSON-like).
Example: // +kubebuilder:validation:Enum={"crackers, Gromit, we forgot the crackers!","not even wensleydale?"}. [1][2]
Notes:
- controller-gen writes those exact values into the CRD enum and matches them exactly at runtime. Use the brace/quoted form when values contain spaces or characters that would be ambiguous with the semicolon syntax. [1][2]
Sources:
[1] Kubebuilder markers docs (Enum examples).
[2] Kubebuilder book v3 markers page (semicolon and quoted-list examples).
🏁 Script executed:
# Read the actual file content around lines 126-129
cat -n ./console/v1/types_console_sample.go | sed -n '120,135p'Repository: openshift/api
Length of output: 801
🌐 Web query:
kubebuilder validation Enum marker "Enum:=" syntax colon equals
💡 Result:
Short answer: there is no special "colon‑equals" operator — the correct marker syntax uses =. What you may be seeing is the marker name including a colon (e.g. items:Enum) followed by =, which can look like ":=" when written without spacing. Example forms from the Kubebuilder docs:
- Field enum: // +kubebuilder:validation:Enum=A;B;C. [1]
- Array-items enum: // +kubebuilder:validation:items:Enum=A;B;C (the marker name is items:Enum, then =value). [2]
So "Enum:=" is just the marker name with a colon plus the normal "=" assignment; use +kubebuilder:validation:Enum= or +kubebuilder:validation:items:Enum= as shown in the docs. [1][2]
Sources:
[1] Kubebuilder markers reference — Marker Syntax & Enum examples. [2] Kubebuilder CRD validation reference.
🏁 Script executed:
# Search for how the +enum marker is used in the codebase
rg '\+enum' --type go ./console/v1/ -B 2 -A 2Repository: openshift/api
Length of output: 793
🌐 Web query:
kubebuilder +enum marker controller-gen what does it do
💡 Result:
Short answer: the +kubebuilder:validation:Enum marker tells controller-gen to emit an OpenAPI v3 "enum" validation for that Go field into the generated CRD. controller-gen reads the marker comment on your type/field when you run make manifests (or controller-gen crd ...), and writes the enum list into spec.versions[*].schema.openAPIV3Schema so the API server will validate values. [1][2][3][4]
Notes/usage:
- Syntax: // +kubebuilder:validation:Enum=Val1;Val2;Val3 (values separated by semicolons). [4]
- Check the generated YAML because controller-gen won’t always warn on misspelled markers and nested/omitted fields affect validation. [5]
Sources: Kubebuilder/controller-gen docs and examples. [1][2][3][4][5]
🏁 Script executed:
# Check if there are any recent commits or PRs related to enum changes
git log --oneline --all -20 -- console/v1/types_console_sample.go | head -10Repository: openshift/api
Length of output: 287
🏁 Script executed:
# Search for any documentation or comments about this enum syntax in the repo
rg 'Enum:=' --type go -B 3 -A 3Repository: openshift/api
Length of output: 34841
🌐 Web query:
kubebuilder validation Enum colon-equals syntax ":=" marker
💡 Result:
Kubebuilder/controller-gen markers use = (equals) for arguments (e.g. // +kubebuilder:validation:Enum=One;Two;Three). There is no documented ":=" (colon-equals) marker syntax in the kubebuilder/controller-tools marker docs — if you’re seeing ":=" it’s likely a typo, a different tool’s output, or comes from some other layer. See the marker syntax and Enum examples in the Kubebuilder docs. [1][2]
If you can paste the exact comment or generated CRD showing ":=", I’ll inspect it and explain where it came from and how to fix it.
Sources:
- Kubebuilder markers reference — Marker syntax and Enum examples. [1] https://book-v2.book.kubebuilder.io/reference/markers
- Kubebuilder CRD validation docs — Enum usage examples. [2] https://book.kubebuilder.io/reference/markers/crd-validation
Fix enum marker syntax: remove colon from Enum:=.
The marker uses Enum:= which is not standard kubebuilder/controller-tools syntax. The correct form is Enum= with an equals sign only. Update line 128 to:
// +kubebuilder:validation:Enum={"GitImport","ContainerImport"}
The colon character will cause controller-gen to misparse or ignore the marker, potentially failing to emit enum validation into the generated CRD.
🤖 Prompt for AI Agents
In `@console/v1/types_console_sample.go` around lines 126 - 129, The kubebuilder
enum marker above the ConsoleSampleSourceType definition uses the wrong syntax
(`Enum:=`) and should be replaced with the standard form using an equals sign
and a JSON-style list of values; update the marker on the
ConsoleSampleSourceType enum to use `Enum=` and list the allowed values
("GitImport","ContainerImport") in braces so controller-gen emits proper enum
validation.
| x-kubernetes-validations: | ||
| - message: discoveryURL must not contain user info | ||
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | ||
| - message: discoveryURL must be a valid URL | ||
| rule: isURL(self) | ||
| - message: discoveryURL must be a valid https URL | ||
| rule: url(self).getScheme() == 'https' | ||
| - message: discoveryURL must not contain query parameters | ||
| rule: url(self).getQuery().size() == 0 | ||
| - message: discoveryURL must not contain fragments | ||
| rule: self.matches('^[^#]*$') | ||
| - message: discoveryURL must not contain user info | ||
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | ||
| - message: discoveryURL must not contain query parameters | ||
| rule: url(self).getQuery().size() == 0 | ||
| - message: discoveryURL must be a valid https URL | ||
| rule: url(self).getScheme() == 'https' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
fd '0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml' --type fRepository: openshift/api
Length of output: 260
🏁 Script executed:
sed -n '465,490p' payload-manifests/crds/0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yamlRepository: openshift/api
Length of output: 1779
🏁 Script executed:
# Let's check CEL documentation and URL validation behavior
# First, let's see if there are other examples in the codebase
rg "url\(self\)" --type yaml -B2 -A2Repository: openshift/api
Length of output: 50369
🏁 Script executed:
sed -n '472,482p' payload-manifests/crds/0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml | cat -nRepository: openshift/api
Length of output: 884
🌐 Web query:
CEL url() function getQuery() getUserInfo() kubernetes validation rule CEL
💡 Result:
Short summary + examples:
-
URL library: use isURL(string) and url(string) → URL. URL objects expose getScheme(), getHost(), getHostname(), getPort(), getEscapedPath(), and getQuery() to access the parsed query string. Example: url('https://example.com/path?a=1&b=2').getQuery(). [1]
-
request.userInfo: in CEL expressions that run against admission requests the admission request includes userInfo (username, uid, groups, extra). Access it with request.userInfo.username, request.userInfo.groups, etc. (AdmissionReview/AdmissionRequest includes userInfo). Example: request.userInfo.username == 'system:serviceaccount:foo:bar'. [2][3]
-
Authorizer library / getUser-like checks: when an Authorizer variable is available you can build resource or path checks and call .check(verb).allowed() or .reason(). Examples:
- authorizer.group('').resource('pods').namespace('default').check('create').allowed()
- authorizer.path('/healthz').check('get').allowed()
- authorizer.serviceAccount('ns','sa').resource('deployments').check('delete').allowed(). [1]
References:
- Kubernetes CEL docs (URL and authorizer libraries).
- ValidatingAdmissionPolicy / AdmissionRequest docs (request and userInfo in admission requests).
- AdmissionReview / AdmissionRequest API reference (userInfo field).
🌐 Web query:
CEL URL object methods getUserInfo kubernetes validation rule
💡 Result:
Short answer: Kubernetes' CEL URL type exposes getScheme, getHost, getHostname, getPort, getEscapedPath and getQuery — there is no getUserInfo method. Use url(string) to parse and the available accessors above; extract user-info if needed by parsing the raw string (e.g., with regex or string functions) because the URL object in Kubernetes CEL doesn't provide getUserInfo. [1][2]
Examples:
- url('https://example.com:80/').getHost() → 'example.com:80'. [1]
- url('https://example.com/path with spaces/').getEscapedPath() → '/path%20with%20spaces/'. [1]
References: Kubernetes CEL docs (URL library). [1][2]
🌐 Web query:
Kubernetes CEL validation rule user info URL parsing regex pattern
💡 Result:
Short answer + pattern and example.
-
Regex (captures user, pass, host, port, rest):
^(([^:`@/`?#]+)(:([^@/?#]))?@)?([^:/?#]+)(?::([0-9]+))?(.)$Groups: 2=user, 4=password, 5=host, 6=port, 7=path+query+fragment.
-
CEL usage examples:
- Reject any URL containing userinfo:
!self.spec.url.matches('^[a-zA-Z][a-zA-Z0-9+.-]*://[^@]+@') - Extract/check userinfo presence (find userinfo):
self.spec.url.find('^([a-zA-Z][a-zA-Z0-9+.-]://)?([^:`@/`?#]+)(:([^@/?#]))?@').size() > 0
- Reject any URL containing userinfo:
Notes: Kubernetes CEL provides regex and URL libraries; url(...) doesn’t expose userinfo accessors, so use regex on the string field. (kubernetes.io)
Citations:
Fix unguarded url() calls and improve user-info validation
Two issues with the current rules:
-
Unguarded url() calls: Lines 9 and 11 call
url(self).getQuery()andurl(self).getScheme()without first checkingisURL(self), which will cause CEL evaluation errors on invalid URLs. Other variants in the codebase correctly useisURL(self) &&guards. -
Regex for user-info is too narrow: The pattern
^https://.+:.+@.+/.*$requires a colon (password) and a trailing path, allowing URLs likehttps://user:pass@hostto bypass the check. User-info exists whenever@appears in the authority section, regardless of password or path.
Kubernetes CEL URL objects don't expose a getUserInfo() method. Use a regex to detect user-info in the authority: !self.matches('^[a-zA-Z][a-zA-Z0-9+.-]*://[^@/]+@') or similar pattern that rejects any user@ in the scheme+host portion.
Guard url() calls and fix user-info detection
- message: discoveryURL must not contain user info
- rule: '!self.matches(''^https://.+:.+@.+/.*$'')'
+ rule: '!self.matches(''^https://[^@/]+@'')'
- message: discoveryURL must not contain fragments
rule: self.matches('^[^#]*$')
- message: discoveryURL must not contain query parameters
- rule: url(self).getQuery().size() == 0
+ rule: 'isURL(self) && url(self).getQuery().size() == 0'
- message: discoveryURL must be a valid https URL
- rule: url(self).getScheme() == 'https'
+ rule: 'isURL(self) && url(self).getScheme() == ''https'''🤖 Prompt for AI Agents
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml`
around lines 472 - 482, Update the x-kubernetes-validations rules in the
authentication CRD: (1) change the user-info check to reject any user@ in the
scheme+authority portion by using a regex that checks for "scheme://...@", e.g.
negate a match like '^[a-zA-Z][a-zA-Z0-9+.-]*://[^@/]+@', and (2) guard the
url(self) calls in the query and scheme rules by prepending isURL(self) && so
the rules become isURL(self) && url(self).getQuery().size() == 0 and isURL(self)
&& url(self).getScheme() == 'https' so url() is only called on valid URLs;
update the rules in the same x-kubernetes-validations list (the rules
referencing discoveryURL and url(self)) accordingly.
| - message: the fulcioCAData must start with base64 encoding | ||
| of '-----BEGIN CERTIFICATE-----'. | ||
| rule: string(self).startsWith('-----BEGIN CERTIFICATE-----') |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the CRD file around the specified lines to understand the field definitions
head -300 payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml | tail -230Repository: openshift/api
Length of output: 16940
🏁 Script executed:
# Let's look at the specific regions mentioned in the review
echo "=== Lines 70-85 ==="
sed -n '70,85p' payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml
echo -e "\n=== Lines 115-130 ==="
sed -n '115,130p' payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml
echo -e "\n=== Lines 150-165 ==="
sed -n '150,165p' payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yamlRepository: openshift/api
Length of output: 3153
🏁 Script executed:
# Let's get the full context of the fields being validated - search for type definitions
grep -n "type: string\|type: object\|format: byte\|format:" payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml | head -40Repository: openshift/api
Length of output: 1718
🌐 Web query:
Kubernetes CEL validation rules format: byte deserialization
💡 Result:
Short answer: Kubernetes' format.byte expects base64-encoded strings (i.e. "byte" = base64), but Kubernetes' built‑in CEL libraries do not provide a bytes-deserialization function (base64.decode) for use in CRD/validation CEL expressions — you can validate base64 with format.byte(), but you cannot decode it to raw bytes inside the API‑server CEL environment.
Evidence:
- Kubernetes docs: the format library exposes a "byte" format that validates base64 strings. [1]
- Kubernetes apiserver source: format.byte validation uses base64 validation (see format.go/tests). [2][3]
- Some CEL implementations/extensions (e.g. cel-go / other language bindings) do offer base64.decode → bytes, but that encoder extension is not part of the Kubernetes builtin CEL surface for validation rules. (Example docs for a CEL encoder extension showing base64.decode exist in external CEL implementations.) [4]
If you need to operate on decoded bytes in admission/validation logic you have two options:
- Keep validation to "is valid base64" (format.byte()) in CEL and do decoding/inspection in an external admission webhook or controller. [1][2]
- Use an out‑of‑process policy engine (or custom apiserver build) that enables a CEL encoder extension (base64.decode) or provides custom CEL functions. [4]
Sources:
[1] Kubernetes CEL docs — format library (lists "byte" = base64).
[2] k8s apiserver source (format.go) showing "byte" uses base64 validation.
[3] k8s apiserver format tests (format.byte test cases).
[4] Example CEL encoders extension (base64.decode/base64.encode) in external CEL implementations.
🌐 Web query:
Kubernetes x-kubernetes-validations format byte string encoding
💡 Result:
Short answer: use OpenAPI "format: byte" (a base64-encoded string) and CEL's format.byte() / format.named("byte") to validate it. Kubernetes' CEL format library treats format=byte as a base64-encoded string and will validate (and the schema maps string+format=byte to CEL bytes). See Kubernetes CEL docs and the OpenAPI "byte" format definition. [1][2]
Sources:
- Kubernetes CEL "format" library (includes format.byte and notes string+format=byte → bytes). [1]
- OpenAPI format registry: "byte = base64 encoded data (RFC4648)". [2]
🏁 Script executed:
# Let's also check if there are any tests or comments in the repo about this
git log --oneline --all -- payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml | head -20Repository: openshift/api
Length of output: 196
🏁 Script executed:
# Search for any related documentation or comments about PEM validation
rg "base64.*PEM|PEM.*base64|format: byte" --type yaml -B2 -A2 | head -60Repository: openshift/api
Length of output: 7320
CEL validation rules cannot check raw PEM headers against base64-encoded fields
These fields are marked format: byte and described as "base64-encoded data", meaning the apiserver transmits and stores them as base64-encoded strings in YAML/JSON. However, the added CEL rules check for raw PEM headers like '-----BEGIN CERTIFICATE-----'. According to Kubernetes' CEL validation environment, format: byte fields are NOT automatically decoded—CEL rules operate directly on the base64-encoded string values and do not have access to a base64.decode() function. This means these validations will never match their intended patterns.
Affected fields: fulcioCAData (76-78), rekorKeyData (121-123, 271-274), caIntermediatesData (153-155), caRootsData (176-178), keyData (246-248), publicKey.rekorKeyData (261-263)
Either:
- Update the CEL rules to validate the base64-encoded representation (e.g., check the base64 encoding of the PEM headers), or
- Change the field schema to store and transmit raw (unencoded) PEM data and remove
format: byte
🤖 Prompt for AI Agents
In `@payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml`
around lines 76 - 78, The CEL checks are comparing raw PEM headers against
fields encoded as format: byte (base64), so they never match; fix by either (A)
updating the CEL rules for fulcioCAData, rekorKeyData, caIntermediatesData,
caRootsData, keyData, and publicKey.rekorKeyData to validate the base64-encoded
form (e.g., check for base64 encoding of "-----BEGIN CERTIFICATE-----" or
appropriate header prefix) or (B) change those field schemas to remove format:
byte so the API will carry raw PEM text and then adjust/remove the CEL rules to
match raw PEM headers; pick one approach and apply it consistently for all
listed fields.
fad886a to
1cefbcb
Compare
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
payload-manifests/crds/0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml (1)
133-159: Guard path index access to prevent CEL evaluation errorsThe path validation rules on lines 37 and 40 use
self.split('/', 2)[1]without checking if the "/" character exists. Although the earlier rule requires "/" to be present, Kubernetes evaluates each validation rule independently. If a rule evaluation fails (e.g., index out of bounds), it produces a CEL runtime error instead of a clean validation message. The current rules will fail with evaluation errors rather than user-friendly messages for inputs without "/".Add
self.contains('/') &&guard to both path rules:Suggested fix
- message: the path of the key must not be empty and must consist of at least one alphanumeric character, percent-encoded octets, apostrophe, '-', '.', '_', '~', '!', '$', '&', '(', ')', '*', '+', ',', ';', '=', and ':' - rule: self.split('/', 2)[1].matches('[A-Za-z0-9/\\-._~%!$&\'()*+;=:]+') + rule: self.contains('/') && self.split('/', 2)[1].matches('[A-Za-z0-9/\\-._~%!$&\'()*+;=:]+') - message: the path of the key must not exceed 256 characters in length - rule: self.split('/', 2)[1].size() <= 256 + rule: self.contains('/') && self.split('/', 2)[1].size() <= 256
🤖 Fix all issues with AI agents
In `@openapi/generated_openapi/zz_generated.openapi.go`:
- Around line 26041-26045: The generated OpenAPI schema incorrectly sets
Default: "" on a required enum property (the "type" field from
console/v1/types_console_sample.go) which violates the spec; update the codegen
logic in tools/codegen/cmd/openapi.go (the routine that builds schema properties
for zz_generated.openapi.go) to skip emitting a Default value when the property
is marked required or when an Enum is present (e.g., if schema.Enum != nil &&
len(schema.Enum) > 0) and avoid setting empty-string defaults; ensure the
generator either omits Default for required fields or only writes defaults that
are valid enum members.
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-CustomNoUpgrade.crd.yaml`:
- Around line 473-482: The discoveryURL user-info check (the rule attached to
the "discoveryURL must not contain user info" message) only blocks "user:pass@"
forms and misses "user@host" forms; update that rule to reject any URL
containing an '@' before the first '/' in the path (i.e., detect any userinfo
portion before the host separator) so URLs like
"https://user@issuer.example.com/..." are caught; replace the current
regex-based rule on discoveryURL with one that matches an '@' appearing in the
authority portion (before the first slash) and keep it negated as the validation
condition.
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-TechPreviewNoUpgrade.crd.yaml`:
- Around line 473-482: The discoveryURL user-info check currently only rejects
user:pass@ forms via the rule '!self.matches(''^https://.+:.+@.+/.*$'')' but
misses user@host URLs; update that rule to reject any '@' before the first '/'
by replacing the regex with one that matches any userinfo (for example change to
'!self.matches(''^https://[^/]*@.+/.*$'')') so discoveryURL validation in the
CRD (the rule alongside the messages "discoveryURL must not contain user
info"/"discoveryURL must be a valid URL") will catch both user:pass@ and
user@host forms.
In `@tools/go.mod`:
- Line 38: Remove the temporary replace directive that points
sigs.k8s.io/controller-tools to the personal fork (the line beginning "replace
sigs.k8s.io/controller-tools => github.com/jaypoulz/controller-tools ...") and
instead use the upstream module; update the dependency for
sigs.k8s.io/controller-tools to v0.18.0 (or later) in the module requires so the
code relies on the upstream sigs.k8s.io/controller-tools at v0.18.0+ rather than
the jaypoulz fork.
♻️ Duplicate comments (4)
config/v1/tests/infrastructures.config.openshift.io/DyanmicServiceEndpointIBMCloud.yaml (1)
53-53: Remove the trailing]in the expected error string.Line 53 still ends the message with an extra closing bracket, which makes this test expectation inconsistent with the other multi-error entries.
🛠️ Proposed fix
- expectedError: "spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": url must be a valid absolute URL, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url path must match /v[0,9]+ or /api/v[0,9]+, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url must use https scheme]" + expectedError: "spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": url must be a valid absolute URL, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url path must match /v[0,9]+ or /api/v[0,9]+, spec.platformSpec.ibmcloud.serviceEndpoints[0].url: Invalid value: \"string\": URL parse error during conversion from string: parse \" \": invalid URI for request evaluating rule: url must use https scheme"console/v1/types_console_sample.go (1)
126-130: Verify theEnum:=marker syntax with the updated controller-tools.A previous review flagged the
:=syntax in+kubebuilder:validation:Enum:=as potentially non-standard. However, this same pattern is used elsewhere in the file (line 117:MaxItems:=10), and the PR explicitly updates controller-tools with enum marker format changes.The combination of the type-level enum validation with the
+enummarker is a reasonable approach to centralize the constraint at the enum definition rather than on each field usage.Please confirm the generated CRD correctly emits the enum validation by inspecting the output schema after running
make manifestsor equivalent.payload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml (1)
76-78: PEM header checks compare raw text against base64 data.These fields are
format: byte(base64-encoded). CEL evaluates the encoded string, sostartsWith('-----BEGIN …-----')will never match. Either switch these fields to raw PEM (dropformat: byte) or compare against the base64-encoded header prefix (and update the existingendsWithchecks similarly).For example,
-----BEGIN CERTIFICATE-----encodes toLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tand-----BEGIN PUBLIC KEY-----encodes toLS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0t.Also applies to: 121-123, 153-155, 176-178, 246-248, 261-263
payload-manifests/crds/0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml (1)
472-482: Harden discoveryURL validations (userinfo + url() guards)
url(self)is still unguarded; CEL evaluates each rule independently, so invalid URLs can raise evaluation errors even whenisURL(self)fails. Also the user‑info regex only catchesuser:pass@host/and missesuser@hostor missing path. UseisURL(self) &&guards and a broader user‑info regex.🛠️ Suggested fix
- - message: discoveryURL must not contain user info - rule: '!self.matches(''^https://.+:.+@.+/.*$'')' + - message: discoveryURL must not contain user info + rule: '!self.matches(''^[a-zA-Z][a-zA-Z0-9+.-]*://[^@/]+@'')' - message: discoveryURL must be a valid URL rule: isURL(self) - message: discoveryURL must not contain fragments rule: self.matches('^[^#]*$') - message: discoveryURL must not contain query parameters - rule: url(self).getQuery().size() == 0 + rule: isURL(self) && url(self).getQuery().size() == 0 - message: discoveryURL must be a valid https URL - rule: url(self).getScheme() == 'https' + rule: isURL(self) && url(self).getScheme() == 'https'Kubernetes CEL URL library url() getQuery getScheme and regex patterns for userinfo in URLs
| - message: discoveryURL must not contain user info | ||
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | ||
| - message: discoveryURL must be a valid URL | ||
| rule: isURL(self) | ||
| - message: discoveryURL must be a valid https URL | ||
| rule: url(self).getScheme() == 'https' | ||
| - message: discoveryURL must not contain query parameters | ||
| rule: url(self).getQuery().size() == 0 | ||
| - message: discoveryURL must not contain fragments | ||
| rule: self.matches('^[^#]*$') | ||
| - message: discoveryURL must not contain user info | ||
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | ||
| - message: discoveryURL must not contain query parameters | ||
| rule: url(self).getQuery().size() == 0 | ||
| - message: discoveryURL must be a valid https URL | ||
| rule: url(self).getScheme() == 'https' |
There was a problem hiding this comment.
User-info regex misses user@host URLs.
The current pattern only blocks user:pass@. A URL like https://user@issuer.example.com/... still passes. Consider matching any @ before the first /.
💡 Proposed fix
- - message: discoveryURL must not contain user info
- rule: '!self.matches(''^https://.+:.+@.+/.*$'')'
+ - message: discoveryURL must not contain user info
+ rule: '!self.matches(''^https://[^/]*@.+$'')'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - message: discoveryURL must not contain user info | |
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | |
| - message: discoveryURL must be a valid URL | |
| rule: isURL(self) | |
| - message: discoveryURL must be a valid https URL | |
| rule: url(self).getScheme() == 'https' | |
| - message: discoveryURL must not contain query parameters | |
| rule: url(self).getQuery().size() == 0 | |
| - message: discoveryURL must not contain fragments | |
| rule: self.matches('^[^#]*$') | |
| - message: discoveryURL must not contain user info | |
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | |
| - message: discoveryURL must not contain query parameters | |
| rule: url(self).getQuery().size() == 0 | |
| - message: discoveryURL must be a valid https URL | |
| rule: url(self).getScheme() == 'https' | |
| - message: discoveryURL must not contain user info | |
| rule: '!self.matches(''^https://[^/]*@.+$'')' | |
| - message: discoveryURL must be a valid URL | |
| rule: isURL(self) | |
| - message: discoveryURL must not contain fragments | |
| rule: self.matches('^[^#]*$') | |
| - message: discoveryURL must not contain query parameters | |
| rule: url(self).getQuery().size() == 0 | |
| - message: discoveryURL must be a valid https URL | |
| rule: url(self).getScheme() == 'https' |
🤖 Prompt for AI Agents
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-CustomNoUpgrade.crd.yaml`
around lines 473 - 482, The discoveryURL user-info check (the rule attached to
the "discoveryURL must not contain user info" message) only blocks "user:pass@"
forms and misses "user@host" forms; update that rule to reject any URL
containing an '@' before the first '/' in the path (i.e., detect any userinfo
portion before the host separator) so URLs like
"https://user@issuer.example.com/..." are caught; replace the current
regex-based rule on discoveryURL with one that matches an '@' appearing in the
authority portion (before the first slash) and keep it negated as the validation
condition.
| - message: discoveryURL must not contain user info | ||
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | ||
| - message: discoveryURL must be a valid URL | ||
| rule: isURL(self) | ||
| - message: discoveryURL must be a valid https URL | ||
| rule: url(self).getScheme() == 'https' | ||
| - message: discoveryURL must not contain query parameters | ||
| rule: url(self).getQuery().size() == 0 | ||
| - message: discoveryURL must not contain fragments | ||
| rule: self.matches('^[^#]*$') | ||
| - message: discoveryURL must not contain user info | ||
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | ||
| - message: discoveryURL must not contain query parameters | ||
| rule: url(self).getQuery().size() == 0 | ||
| - message: discoveryURL must be a valid https URL | ||
| rule: url(self).getScheme() == 'https' |
There was a problem hiding this comment.
User-info regex misses user@host URLs.
The pattern only rejects user:pass@ forms, so a URL like https://user@issuer.example.com/... would pass. Consider matching any @ before the first /.
💡 Proposed fix
- - message: discoveryURL must not contain user info
- rule: '!self.matches(''^https://.+:.+@.+/.*$'')'
+ - message: discoveryURL must not contain user info
+ rule: '!self.matches(''^https://[^/]*@.+$'')'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - message: discoveryURL must not contain user info | |
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | |
| - message: discoveryURL must be a valid URL | |
| rule: isURL(self) | |
| - message: discoveryURL must be a valid https URL | |
| rule: url(self).getScheme() == 'https' | |
| - message: discoveryURL must not contain query parameters | |
| rule: url(self).getQuery().size() == 0 | |
| - message: discoveryURL must not contain fragments | |
| rule: self.matches('^[^#]*$') | |
| - message: discoveryURL must not contain user info | |
| rule: '!self.matches(''^https://.+:.+@.+/.*$'')' | |
| - message: discoveryURL must not contain query parameters | |
| rule: url(self).getQuery().size() == 0 | |
| - message: discoveryURL must be a valid https URL | |
| rule: url(self).getScheme() == 'https' | |
| - message: discoveryURL must not contain user info | |
| rule: '!self.matches(''^https://[^/]*@.+$'')' | |
| - message: discoveryURL must be a valid URL | |
| rule: isURL(self) | |
| - message: discoveryURL must not contain fragments | |
| rule: self.matches('^[^#]*$') | |
| - message: discoveryURL must not contain query parameters | |
| rule: url(self).getQuery().size() == 0 | |
| - message: discoveryURL must be a valid https URL | |
| rule: url(self).getScheme() == 'https' |
🤖 Prompt for AI Agents
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-TechPreviewNoUpgrade.crd.yaml`
around lines 473 - 482, The discoveryURL user-info check currently only rejects
user:pass@ forms via the rule '!self.matches(''^https://.+:.+@.+/.*$'')' but
misses user@host URLs; update that rule to reject any '@' before the first '/'
by replacing the regex with one that matches any userinfo (for example change to
'!self.matches(''^https://[^/]*@.+/.*$'')') so discoveryURL validation in the
CRD (the rule alongside the messages "discoveryURL must not contain user
info"/"discoveryURL must be a valid URL") will catch both user:pass@ and
user@host forms.
tools/go.mod
Outdated
| ) | ||
|
|
||
| replace sigs.k8s.io/controller-tools => github.com/openshift/controller-tools v0.12.1-0.20250801155905-948121310243 | ||
| replace sigs.k8s.io/controller-tools => github.com/jaypoulz/controller-tools v0.0.0-20260119185850-e534bd0a65da |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
kubernetes-sigs controller-tools PR 1324 merged status
💡 Result:
I couldn't find a pull request numbered 1324 in the kubernetes-sigs/controller-tools repository. The repository's PR list is here for you to check (search/filter by number or link): [1].
If you have a specific PR link or a different repo name (or a different PR number), send it and I'll check the merged/closed status and provide details.
Source:
[1] kubernetes-sigs/controller-tools pull requests (GitHub).
🌐 Web query:
Go 1.25 release date availability
💡 Result:
Go 1.25 was released and made available on August 12, 2025 (binaries/installers on the Go download page). [1][2]
Sources:
[1] Go blog announcement, "Go 1.25 is released" (Aug 12, 2025).
[2] Go 1.25 Release Notes (Go.dev).
🏁 Script executed:
# Attempt to verify commit in fork using git
# Check if we can find any reference to this controller-tools fork or commit
rg "jaypoulz/controller-tools" --type go --type mod
rg "e534bd0a65da" --type go --type modRepository: openshift/api
Length of output: 112
🌐 Web query:
controller-tools Go 1.25 compatibility kubernetes-sigs
💡 Result:
Short answer: There’s no official public statement that controller-tools explicitly supports Go 1.25 yet. The controller-tools README lists the minimum Go version for the latest documented CT release (v0.17) as Go 1.23, and controller-runtime (the closely related project) documents minimum Go 1.24 for its recent releases — so for Go 1.25 you should check the specific controller-tools release’s go.mod (or test it) before upgrading. [1][2][3]
Sources
- controller-tools README (compatibility / minimum Go versions). [1]
- controller-runtime compatibility (minimum Go 1.24 for recent releases). [2]
- Kubebuilder / related issues noting Go tool-version changes and the need to track tool versions in go.mod. [3]
🌐 Web query:
openshift kubernetes-sigs-controller-tools PR 33 status
💡 Result:
Do you mean PR #33 in the openshift fork (github.com/openshift/controller-tools) or PR #33 in the upstream kubernetes-sigs/controller-tools repo?
🌐 Web query:
controller-tools kubernetes 1.32 Go 1.25 compatibility
💡 Result:
Short answer: Yes — use controller-tools v0.17 (built/tested against client-go v0.32 / K8s v1.32), which has a minimum Go requirement of 1.23, so Go 1.25 is fine. Check the controller-tools go.mod for the exact tag you plan to use if you need absolute guarantees. [1][2][3]
Sources:
- controller-tools compatibility table (client-go v0.32 → CT v0.17; min Go 1.23). [1]
- controller-runtime compatibility table (client-go v0.32 → CR v0.20; min Go 1.23). [2]
- Kubebuilder release notes (shows related upgrades and recommends checking scaffolded go.mod/Makefile). [3]
References:
[1] https://github.com/kubernetes-sigs/controller-tools
[2] https://github.com/kubernetes-sigs/controller-runtime
[3] https://github.com/kubernetes-sigs/kubebuilder/releases
🏁 Script executed:
cat -n tools/go.modRepository: openshift/api
Length of output: 19860
Migrate controller-tools from personal fork to upstream now that Go 1.25 is available.
The PR objectives indicated the personal fork (jaypoulz/controller-tools) would be used temporarily until Go 1.25 became available for bumping. Go 1.25 was released August 12, 2025, making that condition met. The fork should be removed and sigs.k8s.io/controller-tools should be upgraded to v0.18.0 or later (which supports Go 1.25). Update line 38 to remove the replace directive and rely on the upstream version specified in line 32.
🤖 Prompt for AI Agents
In `@tools/go.mod` at line 38, Remove the temporary replace directive that points
sigs.k8s.io/controller-tools to the personal fork (the line beginning "replace
sigs.k8s.io/controller-tools => github.com/jaypoulz/controller-tools ...") and
instead use the upstream module; update the dependency for
sigs.k8s.io/controller-tools to v0.18.0 (or later) in the module requires so the
code relies on the upstream sigs.k8s.io/controller-tools at v0.18.0+ rather than
the jaypoulz fork.
1cefbcb to
deff7a9
Compare
openshift-ci
bot
added
size/L
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@openapi/openapi.json`:
- Around line 14423-14430: The schema for the "type" property declares
"default": "" which is not a valid enum member ("ContainerImport","GitImport");
update the "type" property schema by either removing the "default" key or
changing it to a valid enum value (e.g., "ContainerImport" or "GitImport"), or
if an empty string is intentionally allowed add "" to the "enum" list; if this
OpenAPI was generated, fix the source generator/templates that emit the "type"
property's default and re-generate so the default and enum remain consistent.
♻️ Duplicate comments (2)
console/v1/types_console_sample.go (1)
128-129: Enum marker syntax concern already flagged;+enumaddition is appropriate.The
Enum:=syntax issue was previously raised. The addition of the+enummarker on line 129 is correct practice for enabling proper enum type generation in controller-gen output.If the
:=syntax is intentionally supported by the jaypoulz/controller-tools fork referenced in this PR, please confirm. Otherwise, consider addressing the prior feedback to use standardEnum=syntax.openapi/generated_openapi/zz_generated.openapi.go (1)
26041-26045: Remove invalid default on enum schema.
Default: ""conflicts with the enum values and makes the schema invalid. Please omit the default (or set it to a valid enum member) in the generator rather than in this generated file.🛠️ Suggested change (generated output)
- Default: "",
🧹 Nitpick comments (1)
openapi/openapi.json (1)
24713-24716: The enum values are defined in the source but not appearing in the generated OpenAPI—regenerate to enforce validation.The
+kubebuilder:validation:Enum=MachineAPI;ClusterAPImarker already exists on theSynchronizedAPItype in the source (machine/v1beta1/types_machine.go), but the generated OpenAPI schema (openapi/openapi.json) is not including theenumconstraint. Regenerating the OpenAPI usinghack/update-openapi.shshould translate these markers into the schema. This will enforce the valid values at the API level instead of relying on documentation alone.Regarding default values: enum constraints and default values are independent. Default values do not need to be included in the enum list; an enum validates the field's value when present.
| // RetentionType is the enumeration of valid retention policy types. | ||
| // +kubebuilder:validation:Enum:="";"RetentionNumber";"RetentionSize" | ||
| // +enum | ||
| // +kubebuilder:validation:Enum:="RetentionNumber";"RetentionSize" | ||
| type RetentionType string |
There was a problem hiding this comment.
| // RetentionType is the enumeration of valid retention policy types. | |
| // +kubebuilder:validation:Enum:="";"RetentionNumber";"RetentionSize" | |
| // +enum | |
| // +kubebuilder:validation:Enum:="RetentionNumber";"RetentionSize" | |
| type RetentionType string | |
| // RetentionType is the enumeration of valid retention policy types. | |
| // +enum | |
| // +kubebuilder:validation:Enum:="RetentionNumber";"RetentionSize" | |
| type RetentionType string |
|
|
||
| $(OUTPUT_DIR)/openapi-gen: $(OUTPUT_DIR)/vendor-version | ||
| go build -mod=vendor -o $(OUTPUT_DIR)/openapi-gen ./vendor/k8s.io/code-generator/cmd/openapi-gen | ||
| go build -mod=vendor -o $(OUTPUT_DIR)/openapi-gen ./vendor/k8s.io/kube-openapi/cmd/openapi-gen |
There was a problem hiding this comment.
How come this is changing? 🤔 Appears not to be affecting anything, was the previous location deprecated?
There was a problem hiding this comment.
I couldn't build without it. I'm not sure why. I assumed this was changed upstream?
There was a problem hiding this comment.
Announcement: https://groups.google.com/a/kubernetes.io/g/dev/c/Ix-ACY9DhEs
Introducer: 9104a79
jaypoulz
force-pushed
the
OCPEDGE-2084-xvalidation-strict-order
branch
2 times, most recently
from
bfd09a1 to
8ba20ea
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@console/v1/types_console_sample.go`:
- Around line 128-129: The kubebuilder marker uses the wrong syntax: replace the
non-standard `// +kubebuilder:validation:Enum:="GitImport";"ContainerImport"`
marker with the proper form by removing the extra colon and quotes so it reads
`// +kubebuilder:validation:Enum=GitImport;ContainerImport`; update the Enum
marker near the type declaration in types_console_sample.go (the kubebuilder
`Enum` tag for the sample type) so values are unquoted and separated by
semicolons.
♻️ Duplicate comments (1)
openapi/openapi.json (1)
14423-14430: Default value is not in enum (schema-invalid).
Line 14426 sets"default": "", but the enum only allows"ContainerImport"and"GitImport". This makes the schema inconsistent and can break validation/defaulting. If this file is generated, fix the source markers and re-generate.🐛 Proposed fix (if empty string is not allowed)
- "default": "", "enum": [ "ContainerImport", "GitImport" ]
🧹 Nitpick comments (1)
openapi/openapi.json (1)
24713-24716: Add enum to enforce the documented valid values.
The description states valid values are"MachineAPI"and"ClusterAPI", but the schema allows any string. If those are the only valid values, add an enum so validation matches the contract.♻️ Suggested change (apply in both locations)
"synchronizedAPI": { "description": "synchronizedAPI holds the last stable value of authoritativeAPI. It is used to detect migration cancellation requests and to restore the resource to its previous state. Valid values are \"MachineAPI\" and \"ClusterAPI\". When omitted, the resource has not yet been reconciled by the migration controller.", - "type": "string" + "type": "string", + "enum": [ + "MachineAPI", + "ClusterAPI" + ] },Also applies to: 24820-24823
| // +kubebuilder:validation:Enum:="GitImport";"ContainerImport" | ||
| // +enum |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for enum values in the generated OpenAPI file
fd -e go -path "*generated*openapi*" | head -5Repository: openshift/api
Length of output: 225
🏁 Script executed:
# Check what enum marker syntax is used in the codebase
rg '\+kubebuilder:validation:Enum' --type go -B 2 -A 2 | head -60Repository: openshift/api
Length of output: 4190
🌐 Web query:
kubebuilder controller-gen validation Enum marker syntax documentation
💡 Result:
Short answer — use the +kubebuilder:validation:Enum marker with either semicolon-separated values or a quoted Go-syntax slice. Examples:
-
Simple semicolon list (strings without quotes):
// +kubebuilder:validation:Enum=Wallace;Gromit;Chicken. [1][2] -
Quoted/complex values (Go-syntax slice / curly braces):
// +kubebuilder:validation:Enum={"crackers, Gromit, we forgot the crackers!","not even wensleydale?"}. [1][2] -
For array items use the items form:
// +kubebuilder:validation:items:Enum=one;two;three. [1]
Reference: Kubebuilder marker docs — CRD validation and marker-syntax. [1][2]
Sources
[1] CRD Validation — The Kubebuilder Book.
[2] Markers for Config/Code Generation — The Kubebuilder Book.
Fix the non-standard Enum:= marker syntax.
The correct kubebuilder marker syntax uses Enum= (not Enum:=), with unquoted semicolon-separated values: // +kubebuilder:validation:Enum=GitImport;ContainerImport. Change line 128 from:
// +kubebuilder:validation:Enum:="GitImport";"ContainerImport"
to:
// +kubebuilder:validation:Enum=GitImport;ContainerImport
🤖 Prompt for AI Agents
In `@console/v1/types_console_sample.go` around lines 128 - 129, The kubebuilder
marker uses the wrong syntax: replace the non-standard `//
+kubebuilder:validation:Enum:="GitImport";"ContainerImport"` marker with the
proper form by removing the extra colon and quotes so it reads `//
+kubebuilder:validation:Enum=GitImport;ContainerImport`; update the Enum marker
near the type declaration in types_console_sample.go (the kubebuilder `Enum` tag
for the sample type) so values are unquoted and separated by semicolons.
There was a problem hiding this comment.
While this feedback points to the correct/preferred semantic, the existing tag is actually ok and works just fine, we don't need to call out these differences
There was a problem hiding this comment.
@JoelSpeed Thank you for the clarification! I understand that both the quoted syntax (Enum:="GitImport";"ContainerImport") and the unquoted syntax (Enum=GitImport;ContainerImport) work correctly. I'll avoid flagging these differences in the future.
Learnings added:
Applicable to openshift/api
Learnings added (1):
User: JoelSpeed
PR: openshift/api#2658
File: console/v1/types_console_sample.go:128-129
Timestamp: 2026-01-20T...
Learning: Both kubebuilder validation Enum marker syntaxes are acceptable in the openshift/api repository: the quoted syntax `+kubebuilder:validation:Enum:="Value1";"Value2"` and the unquoted syntax `+kubebuilder:validation:Enum=Value1;Value2` both work correctly. Do not flag these differences as issues in code reviews.
8ba20ea to
0957323
Compare
|
@jaypoulz: This pull request references OCPEDGE-2084 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@openapi/openapi.json`:
- Around line 24713-24716: The schema for the synchronizedAPI field currently
declares only type: "string" but the description restricts values to
"MachineAPI" and "ClusterAPI"; update the synchronizedAPI schema(s) to include
an enum: ["MachineAPI","ClusterAPI"] (apply to both occurrences of the
synchronizedAPI property) so the OpenAPI spec enforces the valid values, or
alternatively change the description to remove the stricter wording if you do
not want validation. Use the property name synchronizedAPI to locate and modify
both schema blocks.
♻️ Duplicate comments (1)
openapi/openapi.json (1)
14423-14430: Default value doesn’t match enum.
Line 14426 sets"default": ""but Line 14427-14430 only allow"ContainerImport"or"GitImport", which can make the schema invalid or break defaulting. Remove the default or include""in the enum (if intentionally allowed), and regenerate from the source markers/templates if this file is generated.🐛 Proposed fix (if empty string is not valid)
"type": "string", - "default": "", "enum": [ "ContainerImport", "GitImport" ]
| "synchronizedAPI": { | ||
| "description": "synchronizedAPI holds the last stable value of authoritativeAPI. It is used to detect migration cancellation requests and to restore the resource to its previous state. Valid values are \"MachineAPI\" and \"ClusterAPI\". When omitted, the resource has not yet been reconciled by the migration controller.", | ||
| "type": "string" | ||
| }, |
There was a problem hiding this comment.
Schema doesn’t enforce the stated valid values.
The description says valid values are "MachineAPI" and "ClusterAPI", but the schema is just type: "string". If those are the only valid values, add an enum (and regenerate from source markers); otherwise, soften the description to avoid implying strict validation.
🔧 Suggested schema tightening (apply to both locations)
"synchronizedAPI": {
"description": "synchronizedAPI holds the last stable value of authoritativeAPI. It is used to detect migration cancellation requests and to restore the resource to its previous state. Valid values are \"MachineAPI\" and \"ClusterAPI\". When omitted, the resource has not yet been reconciled by the migration controller.",
- "type": "string"
+ "type": "string",
+ "enum": [
+ "MachineAPI",
+ "ClusterAPI"
+ ]
},Also applies to: 24820-24823
🤖 Prompt for AI Agents
In `@openapi/openapi.json` around lines 24713 - 24716, The schema for the
synchronizedAPI field currently declares only type: "string" but the description
restricts values to "MachineAPI" and "ClusterAPI"; update the synchronizedAPI
schema(s) to include an enum: ["MachineAPI","ClusterAPI"] (apply to both
occurrences of the synchronizedAPI property) so the OpenAPI spec enforces the
valid values, or alternatively change the description to remove the stricter
wording if you do not want validation. Use the property name synchronizedAPI to
locate and modify both schema blocks.
Update controller-tools to openshift/kubernetes-sigs-controller-tools which includes a fix for deterministic XValidation rule ordering. This ensures CRD generation produces consistent output. Changes included: - tools/go.mod: Point replace directive to openshift fork with stable sort fix - tools/Makefile: Fix openapi-gen path (moved from code-generator to kube-openapi upstream) - tools/codegen/pkg/schemacheck/generator.go: Disable NoDataTypeChange comparator for allOf→enum schema simplification The new controller-tools generates simpler enum schemas without allOf wrappers when both type and field have enum markers. This is functionally equivalent but structurally different, requiring the schemacheck adjustment to avoid false positive violations. Upstream fix: kubernetes-sigs/controller-tools#1299 OpenShift carry: openshift/kubernetes-sigs-controller-tools#35 Created with support from Claude Opus 4 (Anthropic)
jaypoulz
force-pushed
the
OCPEDGE-2084-xvalidation-strict-order
branch
from
0957323 to
98cf846
Compare
|
@jaypoulz: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
payload-manifests/crds/0000_10_config-operator_01_backups-TechPreviewNoUpgrade.crd.yaml (1)
92-104: Update description to remove misleading empty string reference.The
retentionTypefield description (line 96) states "Empty string means no opinion and the platform is left to choose a reasonable default," but the enum (lines 98-100) only allowsRetentionNumberandRetentionSize. Since the field is markedrequired, empty string is not a valid option. This inconsistency is repeated across all backup CRD variants (CustomNoUpgrade, DevPreviewNoUpgrade, TechPreviewNoUpgrade).Update the description to remove the empty string reference or clarify that defaults are chosen only when the entire
retentionPolicyobject is omitted, not by providing an emptyretentionType.
♻️ Duplicate comments (3)
payload-manifests/crds/0000_10_config-operator_01_backups-CustomNoUpgrade.crd.yaml (1)
92-104: Same documentation inconsistency as noted in the TechPreviewNoUpgrade variant.The description references empty string as valid (line 96), but the enum constraint (lines 98-100) does not allow it. Since this CRD is generated from
config/v1alpha1/types_backup.go, the fix should be applied to the sourceEtcdBackupSpec.RetentionPolicyfield documentation in that file, then regenerated.openapi/openapi.json (2)
14423-14430: Default value""is not a valid enum member.The schema defines
"default": ""but the enum only includes["ContainerImport", "GitImport"]. This makes the default value invalid according to the schema's own constraints. Either remove the default, change it to a valid enum value, or add""to the enum if it's intentionally allowed.Since this file is generated, the fix should be applied to the source markers (likely in
console/v1/types_console_sample.go) and then regenerated.
24713-24716: Description states valid values but schema lacks enum constraint.Both
synchronizedAPIfield instances describe valid values as"MachineAPI"and"ClusterAPI", yet the schema only specifies"type": "string"without an enum. This means the OpenAPI spec won't enforce the documented constraint.If these are the only valid values, add an enum to the schema (and regenerate from source); otherwise, soften the description to avoid implying strict validation.
Also applies to: 24820-24823
3 participants
User description
Update controller-tools to openshift/kubernetes-sigs-controller-tools which
includes a fix for deterministic XValidation rule ordering. This ensures CRD
generation produces consistent output.
Changes included:
kube-openapi upstream)
comparator for allOf→enum schema simplification
The new controller-tools generates simpler enum schemas without allOf
wrappers when both type and field have enum markers. This is functionally
equivalent but structurally different, requiring the schemacheck adjustment
to avoid false positive violations.
Upstream fix: kubernetes-sigs/controller-tools#1299
OpenShift carry: openshift/kubernetes-sigs-controller-tools#35
Created with support from Claude Opus 4 (Anthropic)
PR Type
Enhancement, Bug fix
Description
Upgraded
controller-toolsto include deterministicXValidationrule ordering, ensuring consistent CRD generation output regardless of map iteration orderImplemented sorting of
XValidationsby rule field usingslices.SortFuncwithcmp.Comparefor deterministic outputRefactored schema generation with
schemaFetcherfunction type for improved schema resolution and lazy loading with cachingAdded alphabetical sorting of
Requiredfields in struct schema generationUpdated enum marker formats in type definitions (
RetentionType,ConsoleSampleSourceType) to use quoted values and added+enumannotationsDisabled
NoDataTypeChangecomparator in schema checks to accommodate simplified allOf enum structures from updated controller-toolsRegenerated all CRD manifests with deterministic validation rule ordering across multiple API groups (config, operator, machine, monitoring, route, insights)
Enhanced OpenAPI schema documentation with enum value descriptions
Diagram Walkthrough
File Walkthrough
53 files
schema.go
Schema generation refactoring with deterministic field orderingtools/vendor/sigs.k8s.io/controller-tools/pkg/crd/schema.go
schemaFetcherfunction type for fetching schemas by typeidentifier
schemaFetcherfield toschemaContextstruct for schemaresolution
localNamedToSchemato useschemaFetcherinstead of inlineschema creation logic
Descriptionfield when non-emptyRequiredfields in struct schemageneration
types_backup.go
Enum marker format update for retention policy typesconfig/v1alpha1/types_backup.go
RetentionTypeenum marker format from+kubebuilder:validation:Enum:="RetentionNumber";"RetentionSize"to+kubebuilder:validation:Enum:="";"RetentionNumber";"RetentionSize"+enummarker annotationvalidation.go
Deterministic XValidation rule ordering implementationtools/vendor/sigs.k8s.io/controller-tools/pkg/crd/markers/validation.go
cmpandslicespackagesXValidationsby rule fieldslices.SortFuncwithcmp.Compareto ensure consistent outputorder
parser.go
Schema fetcher integration in parser initializationtools/vendor/sigs.k8s.io/controller-tools/pkg/crd/parser.go
newSchemaContextcall to pass aschemaFetcherfunctionNeedSchemaForand returns cachedschema
zz_generated.openapi.go
OpenAPI schema enhancement with enum documentationopenapi/generated_openapi/zz_generated.openapi.go
ConsoleSampleSourcetype field description with enum valuesdocumentation
Enumfield with sorted enum values["ContainerImport","GitImport"]types_console_sample.go
Console sample source type enum marker format updateconsole/v1/types_console_sample.go
ConsoleSampleSourceTypeenum marker format to use quotedvalues
+kubebuilder:validation:Enum:=GitImport;ContainerImportto
+kubebuilder:validation:Enum:="GitImport";"ContainerImport"+enummarker annotation0000_80_machine-config_01_machineconfigurations-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDoperator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules to achieve deterministicordering
Rebootaction validation rule afterNoneaction validation rulein multiple locations
to ensure consistent output
0000_80_machine-config_01_machineconfigurations-CustomNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDoperator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-CustomNoUpgrade.crd.yaml
x-kubernetes-validationsrules for deterministic outputRebootaction validation afterNoneaction validationconsistently
0000_80_machine-config_01_machineconfigurations-TechPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDoperator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-TechPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for consistent CRD generationRebootaction validation rule afterNoneaction validationBootImageSkewEnforcement.yaml
Deterministic XValidation rule ordering in BootImageSkewEnforcementCRDoperator/v1/zz_generated.featuregated-crd-manifests/machineconfigurations.operator.openshift.io/BootImageSkewEnforcement.yaml
x-kubernetes-validationsrules for deterministic outputRebootaction validation afterNoneaction validation inmultiple sections
level
0000_80_machine-config_01_machineconfigurations-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDpayload-manifests/crds/0000_80_machine-config_01_machineconfigurations-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for consistent CRD generationRebootaction validation afterNoneaction validation0000_80_machine-config_01_machineconfigurations-CustomNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDpayload-manifests/crds/0000_80_machine-config_01_machineconfigurations-CustomNoUpgrade.crd.yaml
x-kubernetes-validationsrules for deterministic outputRebootaction validation afterNoneaction validationconsistently
0000_80_machine-config_01_machineconfigurations-TechPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDpayload-manifests/crds/0000_80_machine-config_01_machineconfigurations-TechPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for consistent CRD generationRebootaction validation afterNoneaction validationSigstoreImageVerificationPKI.yaml
Deterministic XValidation rule ordering inSigstoreImageVerificationPKI CRDconfig/v1alpha1/zz_generated.featuregated-crd-manifests/imagepolicies.config.openshift.io/SigstoreImageVerificationPKI.yaml
x-kubernetes-validationsrules for certificate datavalidation
startsWithvalidation rule after other certificate format checks0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in Authentication CRDconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for key domain validation0000_10_config-operator_01_authentications-CustomNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in Authentication CRDconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_authentications-CustomNoUpgrade.crd.yaml
x-kubernetes-validationsrules for key domain validation0000_10_config-operator_01_authentications-TechPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in Authentication CRDconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_authentications-TechPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for key domain validationManagedBootImages+ManagedBootImagesCPMS.yaml
Deterministic XValidation rule ordering in ManagedBootImages CRDoperator/v1/zz_generated.featuregated-crd-manifests/machineconfigurations.operator.openshift.io/ManagedBootImages+ManagedBootImagesCPMS.yaml
x-kubernetes-validationsrules for action validationRebootaction validation afterNoneaction validation0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDoperator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml
x-kubernetes-validationsrules for action validationRebootaction validation afterNoneaction validationconsistently
0000_80_machine-config_01_machineconfigurations-Default.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDoperator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml
x-kubernetes-validationsrules for action validationRebootaction validation afterNoneaction validationIrreconcilableMachineConfig.yaml
Deterministic XValidation rule ordering in IrreconcilableMachineConfigCRDoperator/v1/zz_generated.featuregated-crd-manifests/machineconfigurations.operator.openshift.io/IrreconcilableMachineConfig.yaml
x-kubernetes-validationsrules for action validationRebootaction validation afterNoneaction validationconsistently
ManagedBootImages.yaml
Deterministic XValidation rule ordering in ManagedBootImages CRDoperator/v1/zz_generated.featuregated-crd-manifests/machineconfigurations.operator.openshift.io/ManagedBootImages.yaml
x-kubernetes-validationsrules for action validationRebootaction validation afterNoneaction validationAAA_ungated.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDoperator/v1/zz_generated.featuregated-crd-manifests/machineconfigurations.operator.openshift.io/AAA_ungated.yaml
x-kubernetes-validationsrules for action validationRebootaction validation afterNoneaction validationconsistently
0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDpayload-manifests/crds/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml
x-kubernetes-validationsrules for action validationRebootaction validation afterNoneaction validation0000_80_machine-config_01_machineconfigurations-Default.crd.yaml
Deterministic XValidation rule ordering in MachineConfiguration CRDpayload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml
x-kubernetes-validationsrules for action validationRebootaction validation afterNoneaction validationconsistently
SigstoreImageVerification.yaml
Deterministic XValidation rule ordering in SigstoreImageVerificationCRDconfig/v1alpha1/zz_generated.featuregated-crd-manifests/clusterimagepolicies.config.openshift.io/SigstoreImageVerification.yaml
x-kubernetes-validationsrules for policy type validationpublicKeyvalidation afterfulcioCAWithRekorvalidation0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in authentication CRDspayload-manifests/crds/0000_10_config-operator_01_authentications-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for authentication keyvalidation to ensure deterministic ordering
openshift.io subdomains) before format validation rules
discoveryURLvalidation rules for consistent CEL ruleordering
issuerURLfield0000_10_config-operator_01_authentications-CustomNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in authentication CRDspayload-manifests/crds/0000_10_config-operator_01_authentications-CustomNoUpgrade.crd.yaml
x-kubernetes-validationsrules for authentication keyvalidation to ensure deterministic ordering
openshift.io subdomains) before format validation rules
discoveryURLvalidation rules for consistent CEL ruleordering
issuerURLfield0000_10_config-operator_01_authentications-TechPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in authentication CRDspayload-manifests/crds/0000_10_config-operator_01_authentications-TechPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for authentication keyvalidation to ensure deterministic ordering
openshift.io subdomains) before format validation rules
discoveryURLvalidation rules for consistent CEL ruleordering
issuerURLfieldExternalOIDCWithUIDAndExtraClaimMappings.yaml
Deterministic XValidation rule ordering in authentication CRDsconfig/v1/zz_generated.featuregated-crd-manifests/authentications.config.openshift.io/ExternalOIDCWithUIDAndExtraClaimMappings.yaml
x-kubernetes-validationsrules for authentication keyvalidation to ensure deterministic ordering
issuerURLfield0000_10_config-operator_01_authentications-OKD.crd.yaml
Deterministic XValidation rule ordering in authentication CRDsconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_authentications-OKD.crd.yaml
x-kubernetes-validationsrules for authentication keyvalidation to ensure deterministic ordering
issuerURLfield0000_10_config-operator_01_authentications-Default.crd.yaml
Deterministic XValidation rule ordering in authentication CRDsconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_authentications-Default.crd.yaml
x-kubernetes-validationsrules for authentication keyvalidation to ensure deterministic ordering
issuerURLfieldDyanmicServiceEndpointIBMCloud.yaml
Deterministic XValidation rule ordering in infrastructure CRDsconfig/v1/zz_generated.featuregated-crd-manifests/infrastructures.config.openshift.io/DyanmicServiceEndpointIBMCloud.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_10_config-operator_01_infrastructures-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in infrastructure CRDsconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_10_config-operator_01_infrastructures-CustomNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in infrastructure CRDsconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-CustomNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_10_config-operator_01_infrastructures-TechPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in infrastructure CRDsconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_infrastructures-TechPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
SigstoreImageVerification.yaml
Deterministic XValidation rule ordering in image policy CRDsconfig/v1alpha1/zz_generated.featuregated-crd-manifests/imagepolicies.config.openshift.io/SigstoreImageVerification.yaml
x-kubernetes-validationsrules for policy type validation(PublicKey, FulcioCAWithRekor)
rule ordering
0000_10_config-operator_01_authentications-OKD.crd.yaml
Deterministic XValidation rule ordering in authentication CRDspayload-manifests/crds/0000_10_config-operator_01_authentications-OKD.crd.yaml
x-kubernetes-validationsrules for authentication keyvalidation to ensure deterministic ordering
issuerURLfield0000_10_config-operator_01_authentications-Default.crd.yaml
Deterministic XValidation rule ordering in authentication CRDspayload-manifests/crds/0000_10_config-operator_01_authentications-Default.crd.yaml
x-kubernetes-validationsrules for authentication keyvalidation to ensure deterministic ordering
issuerURLfield0000_10_config-operator_01_infrastructures-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in infrastructure CRDspayload-manifests/crds/0000_10_config-operator_01_infrastructures-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_10_config-operator_01_infrastructures-CustomNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in infrastructure CRDspayload-manifests/crds/0000_10_config-operator_01_infrastructures-CustomNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_10_config-operator_01_infrastructures-TechPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in infrastructure CRDspayload-manifests/crds/0000_10_config-operator_01_infrastructures-TechPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_80_machine-config_01_controllerconfigs-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in machine config CRDsmachineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_80_machine-config_01_controllerconfigs-CustomNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in machine config CRDsmachineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-CustomNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_80_machine-config_01_controllerconfigs-TechPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in machine config CRDsmachineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_controllerconfigs-TechPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_80_machine-config_01_controllerconfigs-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in machine config CRDspayload-manifests/crds/0000_80_machine-config_01_controllerconfigs-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_80_machine-config_01_controllerconfigs-CustomNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in machine config CRDspayload-manifests/crds/0000_80_machine-config_01_controllerconfigs-CustomNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
0000_80_machine-config_01_controllerconfigs-TechPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in machine config CRDspayload-manifests/crds/0000_80_machine-config_01_controllerconfigs-TechPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
infrastructure
AAA_ungated.yaml
Deterministic XValidation rule ordering in alert relabel CRDsmonitoring/v1/zz_generated.featuregated-crd-manifests/alertrelabelconfigs.monitoring.openshift.io/AAA_ungated.yaml
x-kubernetes-validationsrules for alert relabelconfiguration validation
and targetLabel validation
0000_50_monitoring_02_alertrelabelconfigs.crd.yaml
Deterministic XValidation rule ordering in alert relabel CRDsmonitoring/v1/zz_generated.crd-manifests/0000_50_monitoring_02_alertrelabelconfigs.crd.yaml
x-kubernetes-validationsrules for alert relabelconfiguration validation
and targetLabel validation
VSphereHostVMGroupZonal.yaml
Deterministic XValidation rule ordering in vSphere infrastructure CRDsconfig/v1/zz_generated.featuregated-crd-manifests/infrastructures.config.openshift.io/VSphereHostVMGroupZonal.yaml
x-kubernetes-validationsrules for failure domain identifiertype validation (UUID, Name)
infrastructure
DyanmicServiceEndpointIBMCloud.yaml
Deterministic XValidation rule ordering in machine config CRDsmachineconfiguration/v1/zz_generated.featuregated-crd-manifests/controllerconfigs.machineconfiguration.openshift.io/DyanmicServiceEndpointIBMCloud.yaml
x-kubernetes-validationsrules for dynamic service endpointURL validation
Filters)
0000_10_control-plane-machine-set_01_controlplanemachinesets-DevPreviewNoUpgrade.crd.yaml
Deterministic XValidation rule ordering in control plane machine setCRDsmachine/v1/zz_generated.crd-manifests/0000_10_control-plane-machine-set_01_controlplanemachinesets-DevPreviewNoUpgrade.crd.yaml
x-kubernetes-validationsrules for AWS instance identifiertype validation (ID, ARN, Filters)
GCP, before OpenStack)
machine.openshift.io/cluster-api-clusterlabel1 files
generator.go
Disable schema comparator for enum structure simplificationtools/codegen/pkg/schemacheck/generator.go
NoDataTypeChangeto the list of disabled comparatorsenum structures
simplified enums
13 files
SigstoreImageVerificationPKI.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1/zz_generated.featuregated-crd-manifests/clusterimagepolicies.config.openshift.io/SigstoreImageVerificationPKI.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
and policy type validations
SigstoreImageVerificationPKI.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1/zz_generated.featuregated-crd-manifests/imagepolicies.config.openshift.io/SigstoreImageVerificationPKI.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
and policy type validations
0000_10_config-operator_01_clusterimagepolicies.crd.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_clusterimagepolicies.crd.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
and policy type validations
0000_10_config-operator_01_imagepolicies.crd.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_imagepolicies.crd.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
and policy type validations
0000_10_config-operator_01_clusterimagepolicies.crd.yaml
Deterministic validation rule ordering in CRD manifestspayload-manifests/crds/0000_10_config-operator_01_clusterimagepolicies.crd.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
and policy type validations
0000_10_config-operator_01_imagepolicies.crd.yaml
Deterministic validation rule ordering in CRD manifestspayload-manifests/crds/0000_10_config-operator_01_imagepolicies.crd.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
and policy type validations
SigstoreImageVerification.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1/zz_generated.featuregated-crd-manifests/clusterimagepolicies.config.openshift.io/SigstoreImageVerification.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
validations now sorted deterministically
SigstoreImageVerification.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1/zz_generated.featuregated-crd-manifests/imagepolicies.config.openshift.io/SigstoreImageVerification.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
validations now sorted deterministically
SigstoreImageVerificationPKI.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1alpha1/zz_generated.featuregated-crd-manifests/clusterimagepolicies.config.openshift.io/SigstoreImageVerificationPKI.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
0000_10_config-operator_01_clusterimagepolicies.crd.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clusterimagepolicies.crd.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
0000_10_config-operator_01_imagepolicies.crd.yaml
Deterministic validation rule ordering in CRD manifestsconfig/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_imagepolicies.crd.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
deterministically
AAA_ungated.yaml
Deterministic validation rule ordering in ingress controller CRDoperator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
restrictions now sorted deterministically
0000_50_ingress_00_ingresscontrollers.crd.yaml
Deterministic validation rule ordering in ingress controller CRDoperator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml
x-kubernetes-validationsrules to alphabetical order by rulecontent
restrictions now sorted deterministically
1 files
go.sum
Add jaypoulz controller-tools fork dependencytools/go.sum
github.com/jaypoulz/controller-toolsv0.0.0-20260116180353-88e61f2c62d0fork
101 files