Skip to content

Conversation

@ehearne-redhat
Copy link

This change specifically targets OIDC-specific comments to ensure oc explain, based on CRD generation, will render the Description field in an optimal format i.e. no disjointed lines.

@openshift-ci-robot
Copy link

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
Copy link
Contributor

openshift-ci bot commented Jan 16, 2026

Hello @ehearne-redhat! 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.

@openshift-ci-robot openshift-ci-robot added jira/severity-low Referenced Jira bug's severity is low for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. labels Jan 16, 2026
@openshift-ci-robot
Copy link

@ehearne-redhat: This pull request references Jira Issue OCPBUGS-56851, 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 (4.22.0) matches configured target version for branch (4.22.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @xingxingxia

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

Details

In response to this:

This change specifically targets OIDC-specific comments to ensure oc explain, based on CRD generation, will render the Description field in an optimal format i.e. no disjointed lines.

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.

@coderabbitai
Copy link

coderabbitai bot commented Jan 16, 2026

📝 Walkthrough

Walkthrough

The PR updates documentation strings and formatting across generated Go files, the OpenAPI outputs, and multiple Authentication CRD YAMLs. It also adds a new OpenAPI definition AcceptRisk and new properties: Update.acceptRisks, riskNames, and conditions. No existing public type or method signatures were changed beyond the added OpenAPI definitions and properties; remaining edits are descriptive or formatting-only.

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly describes the main change: reformatting OIDC-related multiline comments into single lines to improve CRD generation and oc explain output formatting.
Description check ✅ Passed The description is directly related to the changeset, explaining the purpose of converting multiline comment fragments into sentence-style lines for better CRD description formatting.

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

✨ Finishing touches
  • 📝 Generate docstrings

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
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 openshift-ci bot requested a review from xingxingxia January 16, 2026 16:59
@openshift-ci openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 16, 2026
@ehearne-redhat
Copy link
Author

@ShazaAldawamneh could you review when you have the chance? :)

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@config/v1/types_authentication.go`:
- Around line 293-296: Update the comment that currently says "must differ from
the value of `url`" to reference `issuerURL` instead so it matches the JSON
field name and existing validation message; locate the block describing
discoveryURL (identifier: discoveryURL) and replace `url` with `issuerURL` to
keep the docstring consistent with issuerURL/validation text.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 36664f7 and 28a3711.

📒 Files selected for processing (1)
  • config/v1/types_authentication.go
🧰 Additional context used
🧬 Code graph analysis (1)
config/v1/types_authentication.go (1)
config/v1/zz_generated.swagger_doc_generated.go (8)
  • TokenIssuer (525-527)
  • TokenClaimMappings (484-486)
  • TokenClaimValidationRule (514-516)
  • ConfigMapNameReference (86-88)
  • UsernameClaimMapping (554-556)
  • PrefixedClaimMapping (464-466)
  • TokenClaimOrExpressionMapping (494-496)
  • SecretNameReference (230-232)
🔇 Additional comments (8)
config/v1/types_authentication.go (8)

201-251: LGTM!

The comment reformatting for the OIDCProvider struct fields successfully consolidates the multiline descriptions into single-line comments. This will improve oc explain output formatting as intended.


310-350: LGTM!

The reformatted comments for TokenClaimMappings fields (username, groups, uid, extra) are clear and maintain the original semantic meaning while achieving the single-line format goal.


468-524: LGTM!

The OIDCClientConfig struct field comments are well-reformatted. The descriptions for componentName, componentNamespace, clientID, clientSecret, and extraScopes remain clear and informative.


526-582: LGTM!

The OIDCClientStatus struct comments are properly reformatted to single-line style while maintaining clarity.


584-610: LGTM!

The OIDCClientReference struct field comments are correctly reformatted.


612-661: LGTM!

The UsernameClaimMapping and UsernamePrefixPolicy documentation changes properly consolidate the multiline descriptions while preserving the detailed examples and behavior documentation for prefix handling.


731-753: LGTM!

The TokenClaimValidationRule struct comments are properly reformatted. The descriptions for the type and requiredClaim fields remain clear.


796-816: LGTM!

The TokenUserValidationRule struct comments are properly reformatted to single-line format.

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

@ehearne-redhat
Copy link
Author

@coderabbitai review

@coderabbitai
Copy link

coderabbitai bot commented Jan 16, 2026

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@openshift-ci openshift-ci bot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 19, 2026
@JoelSpeed
Copy link
Contributor

/assign @everettraven

@ehearne-redhat
Copy link
Author

/test verify

@qodo-code-review
Copy link

qodo-code-review bot commented Jan 19, 2026

PR-Agent: could not fine a component named verify in a supported language in this PR.

@JoelSpeed
Copy link
Contributor

Verify should only fail on this repo if you have out of date generation, I can see in the logs it's showing a diff so you'll need to investigate this

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_authentications-OKD.crd.yaml (1)

375-386: Update description to match enum: remove CEL references from OKD variant.

The description mentions "Allowed values are 'RequiredClaim' and 'CEL'" but the enum constraint only permits RequiredClaim. This inconsistency exists because CEL support is intentionally excluded from the OKD feature set (unlike CustomNoUpgrade, DevPreviewNoUpgrade, and TechPreviewNoUpgrade variants which do include it). Update the description to remove CEL references and only document RequiredClaim for accuracy.

Copy link
Contributor

@everettraven everettraven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, this looks good to me. I've just got a few comments related to using sentences as our natural breakpoints for balancing comment and generated documentation readability.

Do we have a visual representation of the difference that we can show this change makes?

@ehearne-redhat
Copy link
Author

Hey @everettraven - I spun up a kind cluster and applied the old and new CRD authentications . This is an example but I can get more if needed.

OLD

ehearne-mac:api ehearne$ kubectl explain authentication.spec.oidcProviders.claimMappings.extra
GROUP:      config.openshift.io
KIND:       Authentication
VERSION:    v1

FIELD: extra <[]Object>


DESCRIPTION:
    extra is an optional field for configuring the mappings
    used to construct the extra attribute for the cluster identity.
    When omitted, no extra attributes will be present on the cluster identity.
    key values for extra mappings must be unique.
    A maximum of 32 extra attribute mappings may be provided.
    ExtraMapping allows specifying a key and CEL expression
    to evaluate the keys' value. It is used to create additional
    mappings and attributes added to a cluster identity from
    a provided authentication token.
...

NEW:

ehearne-mac:api ehearne$ kubectl explain authentication.spec.oidcProviders.claimMappings.extra
GROUP:      config.openshift.io
KIND:       Authentication
VERSION:    v1

FIELD: extra <[]Object>


DESCRIPTION:
    extra is an optional field for configuring the mappings used to construct
    the extra attribute for the cluster identity.
    When omitted, no extra attributes will be present on the cluster identity.
    
    key values for extra mappings must be unique.
    A maximum of 32 extra attribute mappings may be provided.
    ExtraMapping allows specifying a key and CEL expression
    to evaluate the keys' value. It is used to create additional
    mappings and attributes added to a cluster identity from
    a provided authentication token.
...

@everettraven
Copy link
Contributor

@ehearne-redhat Thanks for that! Do we have a list of what looked to be the worst offenders that we can verify look better with these changes?

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_authentications-OKD.crd.yaml (1)

377-387: Fix doc/schema mismatch for claimValidationRules.type in OKD variant.

The description mentions "Allowed values are 'RequiredClaim' and 'CEL'", but the enum only lists RequiredClaim and the cel field is absent from the schema. This mismatch does not exist in other variants (TechPreviewNoUpgrade, CustomNoUpgrade, DevPreviewNoUpgrade) which correctly include CEL in both the enum and schema. The OKD variant should have its description updated to remove CEL references.

Suggested fix
-                              Allowed values are "RequiredClaim" and "CEL".
-
-                              When 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.
-
-                              When set to 'CEL', the Kubernetes API server will be configured to validate the incoming JWT against the configured CEL expression.
+                              Allowed values are "RequiredClaim".
+
+                              When 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.

@ehearne-redhat
Copy link
Author

Hey @everettraven - I don't have a specific list to hand. However, I believe the ones that were the big offenders were UsernameClaimMapping.Claim, and maybe OIDCClientConfig.ComponentNamespace .

What I'll do is, I'll compile a list of all these changes old vs new, and pick out a few which demonstrate this change best.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

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-CustomNoUpgrade.crd.yaml (1)

101-115: Align key path description with the validation regex.

The description of allowed path characters doesn't mention /, but the CEL regex at line 152 explicitly allows it: [A-Za-z0-9/\\-._~%!$&\'()*+;=:]+. Either add '/' to the documented character list (if intended) or remove it from the regex pattern.

📌 Possible doc-only fix (if `/` is intended)
-                                  The path portion of the key (string of characters after the '/') must not be empty and must consist of at least one alphanumeric character, percent-encoded octets, '-', '.', '_', '~', '!', '$', '&', ''', '(', ')', '*', '+', ',', ';', '=', and ':'.
+                                  The path portion of the key (string of characters after the '/') must not be empty and must consist of at least one alphanumeric character, percent-encoded octets, '/', '-', '.', '_', '~', '!', '$', '&', ''', '(', ')', '*', '+', ',', ';', '=', and ':'.

Also applies to: line 152

🤖 Fix all issues with AI agents
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-Default.crd.yaml`:
- Around line 196-201: Fix the typo in the description for the `prefix` field
where the example contains a double space between `"b" and  "c"`; update the
text inside the `description` block for the `prefix` field (the multiline string
under `description:`) to use a single space so it reads `"b" and "c"`. Ensure
the rest of the wording and punctuation remain unchanged.

@ehearne-redhat
Copy link
Author

Hey @everettraven - I have a few examples here but can get more if needed.

spec.oidcProviders.claimMappings

Before (master)

GROUP:      config.openshift.io
KIND:       Authentication
VERSION:    v1

FIELD: claimMappings <Object>


DESCRIPTION:
    claimMappings is a required field that configures the rules to be used by
    the Kubernetes API server for translating claims in a JWT token, issued
    by the identity provider, to a cluster identity.
    
FIELDS:
  extra	<[]Object>
    extra is an optional field for configuring the mappings
    used to construct the extra attribute for the cluster identity.
    When omitted, no extra attributes will be present on the cluster identity.
    key values for extra mappings must be unique.
    A maximum of 32 extra attribute mappings may be provided.

  groups	<Object>
    groups is an optional field that configures how the groups of a cluster
    identity
    should be constructed from the claims in a JWT token issued
    by the identity provider.
    When referencing a claim, if the claim is present in the JWT
    token, its value must be a list of groups separated by a comma (',').
    For example - '"example"' and '"exampleOne", "exampleTwo", "exampleThree"'
    are valid claim values.

  uid	<Object>
    uid is an optional field for configuring the claim mapping
    used to construct the uid for the cluster identity.
    
    When using uid.claim to specify the claim it must be a single string value.
    When using uid.expression the expression must result in a single string
    value.
    
    When omitted, this means the user has no opinion and the platform
    is left to choose a default, which is subject to change over time.
    The current default is to use the 'sub' claim.

  username	<Object> -required-
    username is a required field that configures how the username of a cluster
    identity
    should be constructed from the claims in a JWT token issued by the identity
    provider.

After (current branch)

GROUP:      config.openshift.io
KIND:       Authentication
VERSION:    v1

FIELD: claimMappings <Object>


DESCRIPTION:
    claimMappings is a required field that configures the rules to be used by
    the Kubernetes API server for translating claims in a JWT token, issued by
    the identity provider, to a cluster identity.
    
FIELDS:
  extra	<[]Object>
    extra is an optional field for configuring the mappings used to construct
    the extra attribute for the cluster identity.
    When omitted, no extra attributes will be present on the cluster identity.
    
    key values for extra mappings must be unique.
    A maximum of 32 extra attribute mappings may be provided.

  groups	<Object>
    groups is an optional field that configures how the groups of a cluster
    identity should be constructed from the claims in a JWT token issued by the
    identity provider.
    
    When referencing a claim, if the claim is present in the JWT token, its
    value must be a list of groups separated by a comma (',').
    
    For example - '"example"' and '"exampleOne", "exampleTwo", "exampleThree"'
    are valid claim values.

  uid	<Object>
    uid is an optional field for configuring the claim mapping used to construct
    the uid for the cluster identity.
    
    When using uid.claim to specify the claim it must be a single string value.
    When using uid.expression the expression must result in a single string
    value.
    
    When omitted, this means the user has no opinion and the platform is left to
    choose a default, which is subject to change over time.
    
    The current default is to use the 'sub' claim.

  username	<Object> -required-
    username is a required field that configures how the username of a cluster
    identity should be constructed from the claims in a JWT token issued by the
    identity provider.

spec.oidcProviders.claimMappings.groups

Before (master)

GROUP:      config.openshift.io
KIND:       Authentication
VERSION:    v1

FIELD: groups <Object>


DESCRIPTION:
    groups is an optional field that configures how the groups of a cluster
    identity
    should be constructed from the claims in a JWT token issued
    by the identity provider.
    When referencing a claim, if the claim is present in the JWT
    token, its value must be a list of groups separated by a comma (',').
    For example - '"example"' and '"exampleOne", "exampleTwo", "exampleThree"'
    are valid claim values.
    
FIELDS:
  claim	<string> -required-
    claim is a required field that configures the JWT token
    claim whose value is assigned to the cluster identity
    field associated with this mapping.

  prefix	<string>
    prefix is an optional field that configures the prefix that will be
    applied to the cluster identity attribute during the process of mapping
    JWT claims to cluster identity attributes.
    
    When omitted (""), no prefix is applied to the cluster identity attribute.
    
    Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains
    an array of strings "a", "b" and  "c", the mapping will result in an
    array of string "myoidc:a", "myoidc:b" and "myoidc:c".

After (current branch)

GROUP:      config.openshift.io
KIND:       Authentication
VERSION:    v1

FIELD: groups <Object>


DESCRIPTION:
    groups is an optional field that configures how the groups of a cluster
    identity should be constructed from the claims in a JWT token issued by the
    identity provider.
    
    When referencing a claim, if the claim is present in the JWT token, its
    value must be a list of groups separated by a comma (',').
    
    For example - '"example"' and '"exampleOne", "exampleTwo", "exampleThree"'
    are valid claim values.
    
FIELDS:
  claim	<string> -required-
    claim is a required field that configures the JWT token claim whose value is
    assigned to the cluster identity field associated with this mapping.

  prefix	<string>
    prefix is an optional field that configures the prefix that will be applied
    to the cluster identity attribute during the process of mapping JWT claims
    to cluster identity attributes.
    
    When omitted (""), no prefix is applied to the cluster identity attribute.
    
    Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains an
    array of strings "a", "b" and  "c", the mapping will result in an array of
    string "myoidc:a", "myoidc:b" and "myoidc:c".


spec.oidcProviders.claimMappings.username

Before (master)

GROUP:      config.openshift.io
KIND:       Authentication
VERSION:    v1

FIELD: username <Object>


DESCRIPTION:
    username is a required field that configures how the username of a cluster
    identity
    should be constructed from the claims in a JWT token issued by the identity
    provider.
    
FIELDS:
  claim	<string> -required-
    claim is a required field that configures the JWT token
    claim whose value is assigned to the cluster identity
    field associated with this mapping.
    
    claim must not be an empty string ("") and must not exceed 256 characters.

  prefix	<Object>
    prefix configures the prefix that should be prepended to the value
    of the JWT claim.
    
    prefix must be set when prefixPolicy is set to 'Prefix' and must be unset
    otherwise.

  prefixPolicy	<string>
  enum: "", NoPrefix, Prefix
    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.
    
    Allowed values are 'Prefix', 'NoPrefix', and omitted (not provided or an
    empty string).
    
    When 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'.
    
    When set to 'NoPrefix', no prefix will be prepended to the value
    of the JWT claim.
    
    When 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:
       `prefix` is unset, `issuerURL` is set to `https://myoidc.tld`,
       the JWT claims include "username":"userA" and "email":"userA@myoidc.tld",
       and `claim` is set to:
       - "username": the mapped value will be "https://myoidc.tld#userA"
       - "email": the mapped value will be "userA@myoidc.tld"

After (current branch)

GROUP:      config.openshift.io
KIND:       Authentication
VERSION:    v1

FIELD: username <Object>


DESCRIPTION:
    username is a required field that configures how the username of a cluster
    identity should be constructed from the claims in a JWT token issued by the
    identity provider.
    
FIELDS:
  claim	<string> -required-
    claim is a required field that configures the JWT token claim whose value is
    assigned to the cluster identity field associated with this mapping.
    
    claim must not be an empty string ("") and must not exceed 256 characters.

  prefix	<Object>
    prefix configures the prefix that should be prepended to the value of the
    JWT claim.
    
    prefix must be set when prefixPolicy is set to 'Prefix' and must be unset
    otherwise.

  prefixPolicy	<string>
  enum: "", NoPrefix, Prefix
    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.
    
    Allowed values are 'Prefix', 'NoPrefix', and omitted (not provided or an
    empty string).
    
    When 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'.
    
    When set to 'NoPrefix', no prefix will be prepended to the value of the JWT
    claim.
    
    When 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:
    
       `prefix` is unset, `issuerURL` is set to `https://myoidc.tld`,
       the JWT claims include "username":"userA" and "email":"userA@myoidc.tld",
       and `claim` is set to:
       - "username": the mapped value will be "https://myoidc.tld#userA"
       - "email": the mapped value will be "userA@myoidc.tld"

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_authentications-OKD.crd.yaml (1)

436-504: Minor grammar nit in extraScopes description.
Line 503: “claim mappings that requires” → “claim mappings that require.”

✅ Proposed fix
-                              This is useful if you have configured claim mappings that requires specific scopes to be requested beyond the standard OIDC scopes.
+                              This is useful if you have configured claim mappings that require specific scopes to be requested beyond the standard OIDC scopes.

Copy link
Contributor

@everettraven everettraven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the before/after comparisons!

Aside from a couple more sentence breaks, this looks good to me.

@ehearne-redhat
Copy link
Author

Hoping I caught those pesky comments ! :D Thanks again @everettraven for the reviews.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-Default.crd.yaml`:
- Around line 196-200: The example text for the `prefix` description contains a
grammatical error ("an array of string") — update the sentence in the `prefix`
field documentation so it reads "an array of strings" (referencing the `prefix`
and `claim` example that maps JWT claim values to cluster identity attributes)
to correct the pluralization in the example description.

Comment on lines +196 to +200
prefix is an optional field that configures the prefix that will be applied to the cluster identity attribute during the process of mapping JWT claims to cluster identity attributes.
When omitted (""), no prefix is applied to the cluster identity attribute.
Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains
an array of strings "a", "b" and "c", the mapping will result in an
array of string "myoidc:a", "myoidc:b" and "myoidc:c".
Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains an array of strings "a", "b" and "c", the mapping will result in an array of string "myoidc:a", "myoidc:b" and "myoidc:c".
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Grammatical error: "an array of string" should be "an array of strings".

Line 200 contains a minor grammatical error in the example text.

Suggested fix
-                                Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains an array of strings "a", "b" and "c", the mapping will result in an array of string "myoidc:a", "myoidc:b" and "myoidc:c".
+                                Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains an array of strings "a", "b" and "c", the mapping will result in an array of strings "myoidc:a", "myoidc:b" and "myoidc:c".
📝 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.

Suggested change
prefix is an optional field that configures the prefix that will be applied to the cluster identity attribute during the process of mapping JWT claims to cluster identity attributes.
When omitted (""), no prefix is applied to the cluster identity attribute.
Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains
an array of strings "a", "b" and "c", the mapping will result in an
array of string "myoidc:a", "myoidc:b" and "myoidc:c".
Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains an array of strings "a", "b" and "c", the mapping will result in an array of string "myoidc:a", "myoidc:b" and "myoidc:c".
prefix is an optional field that configures the prefix that will be applied to the cluster identity attribute during the process of mapping JWT claims to cluster identity attributes.
When omitted (""), no prefix is applied to the cluster identity attribute.
Example: if `prefix` is set to "myoidc:" and the `claim` in JWT contains an array of strings "a", "b" and "c", the mapping will result in an array of strings "myoidc:a", "myoidc:b" and "myoidc:c".
🤖 Prompt for AI Agents
In
`@payload-manifests/crds/0000_10_config-operator_01_authentications-Default.crd.yaml`
around lines 196 - 200, The example text for the `prefix` description contains a
grammatical error ("an array of string") — update the sentence in the `prefix`
field documentation so it reads "an array of strings" (referencing the `prefix`
and `claim` example that maps JWT claim values to cluster identity attributes)
to correct the pluralization in the example description.

Copy link
Contributor

@everettraven everettraven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 20, 2026
@openshift-ci-robot
Copy link

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 20, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: everettraven

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 20, 2026
@ehearne-redhat
Copy link
Author

/retest

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 20, 2026

@ehearne-redhat: all tests passed!

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.

@ehearne-redhat
Copy link
Author

@xingxingxia could you take a look and verify when you have the time? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/severity-low Referenced Jira bug's severity is low for the branch this PR is targeting. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants