OCPBUGS-83754: fix(config/v1): define constants for authentication types as typed constants

[ingvagabund]

Without defining the string literals as typed constants the generated openapi schema produces SchemaProps Enum property with an empty list instead of a list of the string literals.

With this fix the generated openapi diff:

diff --git a/pkg/openapi/zz_generated.openapi.go b/pkg/openapi/zz_generated.openapi.go
index 7d5f0064a..5fe7cf567 100644
--- a/pkg/openapi/zz_generated.openapi.go
+++ b/pkg/openapi/zz_generated.openapi.go
@@ -21060,11 +21060,11 @@ func schema_openshift_api_config_v1_TokenClaimValidationRule(ref common.Referenc
                                Properties: map[string]spec.Schema{
                                        "type": {
                                                SchemaProps: spec.SchemaProps{
-                                                       Description: "type is an optional field that configures the type of the validation rule.\n\nAllowed values are 'RequiredClaim' and omitted (not provided or an empty string).\n\nWhen set to 'RequiredClaim', the Kubernetes API server will be configured to validate that the incoming JWT contains the required claim and that its value matches the required value.\n\nDefaults to 'RequiredClaim'.",
+                                                       Description: "type is an optional field that configures the type of the validation rule.\n\nAllowed values are 'RequiredClaim' and omitted (not provided or an empty string).\n\nWhen set to 'RequiredClaim', the Kubernetes API server will be configured to validate that the incoming JWT contains the required claim and that its value matches the required value.\n\nDefaults to 'RequiredClaim'.\n\n\nPossible enum values:\n - `\"RequiredClaim\"`",
                                                        Default:     "",
                                                        Type:        []string{"string"},
                                                        Format:      "",
-                                                       Enum:        []interface{}{},
+                                                       Enum:        []interface{}{"RequiredClaim"},
                                                },
                                        },
                                        "requiredClaim": {
@@ -21324,11 +21324,11 @@ func schema_openshift_api_config_v1_UsernameClaimMapping(ref common.ReferenceCal
                                        },
                                        "prefixPolicy": {
                                                SchemaProps: spec.SchemaProps{
-                                                       Description: "prefixPolicy is an optional field that configures how a prefix should be applied to the value of the JWT claim specified in the 'claim' field.\n\nAllowed values are 'Prefix', 'NoPrefix', and omitted (not provided or an empty string).\n\nWhen set to 'Prefix', the value specified in the prefix field will be prepended to the value of the JWT claim. The prefix field must be set when prefixPolicy is 'Prefix'.\n\nWhen set to 'NoPrefix', no prefix will be prepended to the value of the JWT claim.\n\nWhen omitted, this means no opinion and the platform is left to choose any prefixes that are applied which is subject to change over time. Currently, the platform prepends `{issuerURL}#` to the value of the JWT claim when the claim is not 'email'. As an example, consider the following scenario:\n   `prefix` is unset, `issuerURL` is set to `https://myoidc.tld`,\n   the JWT claims include \"username\":\"userA\" and \"email\":\"userA@myoidc.tld\",\n   and `claim` is set to:\n   - \"username\": the mapped value will be \"https://myoidc.tld#userA\"\n   - \"email\": the mapped value will be \"userA@myoidc.tld\"",
+                                                       Description: "prefixPolicy is an optional field that configures how a prefix should be applied to the value of the JWT claim specified in the 'claim' field.\n\nAllowed values are 'Prefix', 'NoPrefix', and omitted (not provided or an empty string).\n\nWhen set to 'Prefix', the value specified in the prefix field will be prepended to the value of the JWT claim. The prefix field must be set when prefixPolicy is 'Prefix'.\n\nWhen set to 'NoPrefix', no prefix will be prepended to the value of the JWT claim.\n\nWhen omitted, this means no opinion and the platform is left to choose any prefixes that are applied which is subject to change over time. Currently, the platform prepends `{issuerURL}#` to the value of the JWT claim when the claim is not 'email'. As an example, consider the following scenario:\n   `prefix` is unset, `issuerURL` is set to `https://myoidc.tld`,\n   the JWT claims include \"username\":\"userA\" and \"email\":\"userA@myoidc.tld\",\n   and `claim` is set to:\n   - \"username\": the mapped value will be \"https://myoidc.tld#userA\"\n   - \"email\": the mapped value will be \"userA@myoidc.tld\"\n\n\nPossible enum values:\n - `\"\"` let's the cluster assign prefixes. If the username claim is email, there is no prefix If the username claim is anything else, it is prefixed by the issuerURL\n - `\"NoPrefix\"` means the username claim value will not have any prefix\n - `\"Prefix\"` means the prefix value must be specified. It cannot be empty",
                                                        Default:     "",
                                                        Type:        []string{"string"},
                                                        Format:      "",
-                                                       Enum:        []interface{}{},
+                                                       Enum:        []interface{}{"", "NoPrefix", "Prefix"},
                                                },
                                        },
                                        "prefix": {

[openshift-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

[openshift-ci-robot]

@ingvagabund: This pull request references Jira Issue OCPBUGS-83754, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (5.0.0) matches configured target version for branch (5.0.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Without defining the string literals as typed constants the generated openapi schema produces SchemaProps Enum property with an empty list instead of a list of the string literals.

With this fix the generated openapi diff:

diff --git a/pkg/openapi/zz_generated.openapi.go b/pkg/openapi/zz_generated.openapi.go
index 7d5f0064a..5fe7cf567 100644
--- a/pkg/openapi/zz_generated.openapi.go
+++ b/pkg/openapi/zz_generated.openapi.go
@@ -21060,11 +21060,11 @@ func schema_openshift_api_config_v1_TokenClaimValidationRule(ref common.Referenc
                               Properties: map[string]spec.Schema{
                                       "type": {
                                               SchemaProps: spec.SchemaProps{
-                                                       Description: "type is an optional field that configures the type of the validation rule.\n\nAllowed values are 'RequiredClaim' and omitted (not provided or an empty string).\n\nWhen set to 'RequiredClaim', the Kubernetes API server will be configured to validate that the incoming JWT contains the required claim and that its value matches the required value.\n\nDefaults to 'RequiredClaim'.",
+                                                       Description: "type is an optional field that configures the type of the validation rule.\n\nAllowed values are 'RequiredClaim' and omitted (not provided or an empty string).\n\nWhen set to 'RequiredClaim', the Kubernetes API server will be configured to validate that the incoming JWT contains the required claim and that its value matches the required value.\n\nDefaults to 'RequiredClaim'.\n\n\nPossible enum values:\n - `\"RequiredClaim\"`",
                                                       Default:     "",
                                                       Type:        []string{"string"},
                                                       Format:      "",
-                                                       Enum:        []interface{}{},
+                                                       Enum:        []interface{}{"RequiredClaim"},
                                               },
                                       },
                                       "requiredClaim": {
@@ -21324,11 +21324,11 @@ func schema_openshift_api_config_v1_UsernameClaimMapping(ref common.ReferenceCal
                                       },
                                       "prefixPolicy": {
                                               SchemaProps: spec.SchemaProps{
-                                                       Description: "prefixPolicy is an optional field that configures how a prefix should be applied to the value of the JWT claim specified in the 'claim' field.\n\nAllowed values are 'Prefix', 'NoPrefix', and omitted (not provided or an empty string).\n\nWhen set to 'Prefix', the value specified in the prefix field will be prepended to the value of the JWT claim. The prefix field must be set when prefixPolicy is 'Prefix'.\n\nWhen set to 'NoPrefix', no prefix will be prepended to the value of the JWT claim.\n\nWhen omitted, this means no opinion and the platform is left to choose any prefixes that are applied which is subject to change over time. Currently, the platform prepends `{issuerURL}#` to the value of the JWT claim when the claim is not 'email'. As an example, consider the following scenario:\n   `prefix` is unset, `issuerURL` is set to `https://myoidc.tld`,\n   the JWT claims include \"username\":\"userA\" and \"email\":\"userA@myoidc.tld\",\n   and `claim` is set to:\n   - \"username\": the mapped value will be \"https://myoidc.tld#userA\"\n   - \"email\": the mapped value will be \"userA@myoidc.tld\"",
+                                                       Description: "prefixPolicy is an optional field that configures how a prefix should be applied to the value of the JWT claim specified in the 'claim' field.\n\nAllowed values are 'Prefix', 'NoPrefix', and omitted (not provided or an empty string).\n\nWhen set to 'Prefix', the value specified in the prefix field will be prepended to the value of the JWT claim. The prefix field must be set when prefixPolicy is 'Prefix'.\n\nWhen set to 'NoPrefix', no prefix will be prepended to the value of the JWT claim.\n\nWhen omitted, this means no opinion and the platform is left to choose any prefixes that are applied which is subject to change over time. Currently, the platform prepends `{issuerURL}#` to the value of the JWT claim when the claim is not 'email'. As an example, consider the following scenario:\n   `prefix` is unset, `issuerURL` is set to `https://myoidc.tld`,\n   the JWT claims include \"username\":\"userA\" and \"email\":\"userA@myoidc.tld\",\n   and `claim` is set to:\n   - \"username\": the mapped value will be \"https://myoidc.tld#userA\"\n   - \"email\": the mapped value will be \"userA@myoidc.tld\"\n\n\nPossible enum values:\n - `\"\"` let's the cluster assign prefixes. If the username claim is email, there is no prefix If the username claim is anything else, it is prefixed by the issuerURL\n - `\"NoPrefix\"` means the username claim value will not have any prefix\n - `\"Prefix\"` means the prefix value must be specified. It cannot be empty",
                                                       Default:     "",
                                                       Type:        []string{"string"},
                                                       Format:      "",
-                                                       Enum:        []interface{}{},
+                                                       Enum:        []interface{}{"", "NoPrefix", "Prefix"},
                                               },
                                       },
                                       "prefix": {

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]

Hello @ingvagabund! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: e8223bfe-52a9-4ba9-b14b-de415a2b3b6c

📥 Commits

Reviewing files that changed from the base of the PR and between 33e2dfe and 2873deb.

📒 Files selected for processing (1)

• config/v1/types_authentication.go

---

📝 Walkthrough

Walkthrough

The change modifies constant declarations in the authentication types file. It converts the UsernamePrefixPolicy value block from variables to compile-time constants (NoOpinion, NoPrefix, Prefix). Additionally, it makes the TokenValidationRuleType constants (TokenValidationRuleTypeRequiredClaim and TokenValidationRuleTypeCEL) explicitly typed instead of untyped string constants, while preserving their string literal values.

🚥 Pre-merge checks | ✅ 10

✅ Passed checks (10 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: converting authentication type constants from untyped to typed constants in config/v1.
Description check	✅ Passed	The description explains the problem (empty enum lists in OpenAPI schema) and shows the fix with concrete examples of how the generated OpenAPI improves.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Stable And Deterministic Test Names	✅ Passed	PR only modifies type definitions and constants in config/v1/types_authentication.go without adding or modifying any Ginkgo test files.
Test Structure And Quality	✅ Passed	This PR modifies only config/v1/types_authentication.go, a types definition file with no test code, making the Ginkgo test quality check not applicable.
Microshift Test Compatibility	✅ Passed	The pull request modifies only type definition file config/v1/types_authentication.go with no new Ginkgo e2e tests added, confirming MicroShift compatibility check passes by default.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	This PR only modifies configuration types and constants in a single file without adding Ginkgo e2e tests.
Topology-Aware Scheduling Compatibility	✅ Passed	Pull request modifies only config/v1/types_authentication.go with API schema definition changes; no scheduling-related keywords or deployment manifests detected.
Ote Binary Stdout Contract	✅ Passed	File contains only type and constant declarations with no process-level executable code or stdout writes.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	The pull request does not add any new Ginkgo e2e tests, only modifies type definitions and constants.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

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.11.4)

Error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented
The command is terminated due to an error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign everettraven for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[openshift-ci]

@ingvagabund: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/verify	2873deb	link	true	/test verify

Full PR test history. Your PR dashboard.

Details

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 kubernetes-sigs/prow repository. I understand the commands that are listed here.