OCPNODE-4125: Upgrade to v1 CRIOCredentialProviderConfig

[QiWang19]

Upgrade v1 type CRIOCredentialProviderConfig, manifests, and corresponding empty resource for API GA in 4.22.

API type definition keeps the same as v1alpha1 CRIOCredentialProviderConfig

[openshift-ci-robot]

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]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

Hello @QiWang19! 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]

📝 Walkthrough

Walkthrough

This change introduces the CRIOCredentialProviderConfig resource type in the v1 config group. It includes new type definitions for CRIOCredentialProviderConfig, CRIOCredentialProviderConfigSpec, CRIOCredentialProviderConfigStatus, and CRIOCredentialProviderConfigList, along with supporting types like MatchImage. The resource includes validation rules for image-match patterns and status conditions. Generated code is added for deepcopy operations, Swagger documentation, and CRD manifests. The API version is promoted from v1alpha1 to v1, with the corresponding CRD manifest updated. Type registration in the scheme is added, and a build script entry is removed.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description is directly related to the changeset, explaining the upgrade of CRIOCredentialProviderConfig to v1 for API GA, manifests, and empty resources.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Title check	✅ Passed	The title 'Upgrade to v1 CRIOCredentialProviderConfig' accurately reflects the main objective of this PR, which is to upgrade the CRIOCredentialProviderConfig API from v1alpha1 to v1 for GA release.

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

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{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

[QiWang19]

/test all

[qodo-code-review]

ⓘ Your monthly quota for Qodo has expired. Upgrade your plan

ⓘ Paying users. Check that your Qodo account is linked with this Git user account

[QiWang19]

/test verify

[qodo-code-review]

ⓘ Your monthly quota for Qodo has expired. Upgrade your plan

ⓘ Paying users. Check that your Qodo account is linked with this Git user account

[QiWang19]

/test all

[qodo-code-review]

ⓘ Your monthly quota for Qodo has expired. Upgrade your plan

ⓘ Paying users. Check that your Qodo account is linked with this Git user account

[QiWang19]

/verified by cluster-bot

[openshift-ci-robot]

@QiWang19: This PR has been marked as verified by cluster-bot.

Details

In response to this:

/verified by cluster-bot

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]

Actionable comments posted: 1

🧹 Nitpick comments (1)

config/v1/types_crio_credential_provider_config.go (1)

125-127: Keep documented condition types in sync with declared constants.

Line 125 documents only "Validated" as an expected condition type, but Lines 171–176 also define "MachineConfigRendered". Please document both to avoid API contract drift.

Also applies to: 171-176

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@config/v1/types_crio_credential_provider_config.go` around lines 125 - 127,
The documented list of expected condition types is out of sync with the declared
constants: update the comment block that currently lists only "Validated" to
include both "Validated" and "MachineConfigRendered" so it matches the constants
defined later (the "Validated" and "MachineConfigRendered" condition type
constants in types_crio_credential_provider_config.go); ensure both names are
spelled exactly as the constants and marked +optional if appropriate.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@config/v1/types_crio_credential_provider_config.go`:
- Line 22: Remove the feature-gate annotation that gates the v1 API by deleting
the line containing "+openshift:enable:FeatureGate=CRIOCredentialProviderConfig"
in types_crio_credential_provider_config.go so the v1 CRD is unconditionally
exposed; after removing that annotation, regenerate any CRD manifests or API
docs (e.g., run the project’s codegen/make target) to ensure the CRD and
generated artifacts no longer include the FeatureGate metadata.

---

Nitpick comments:
In `@config/v1/types_crio_credential_provider_config.go`:
- Around line 125-127: The documented list of expected condition types is out of
sync with the declared constants: update the comment block that currently lists
only "Validated" to include both "Validated" and "MachineConfigRendered" so it
matches the constants defined later (the "Validated" and "MachineConfigRendered"
condition type constants in types_crio_credential_provider_config.go); ensure
both names are spelled exactly as the constants and marked +optional if
appropriate.

---

ℹ️ Review info

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 1105fd4 and 4b7758f.

⛔ Files ignored due to path filters (3)

• config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_criocredentialproviderconfigs.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• config/v1/zz_generated.featuregated-crd-manifests/criocredentialproviderconfigs.config.openshift.io/CRIOCredentialProviderConfig.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
• openapi/generated_openapi/zz_generated.openapi.go is excluded by !openapi/**

📒 Files selected for processing (9)

• config/v1/register.go
• config/v1/tests/criocredentialproviderconfigs.config.openshift.io/CRIOCredentialProviderConfig.yaml
• config/v1/types_crio_credential_provider_config.go
• config/v1/zz_generated.deepcopy.go
• config/v1/zz_generated.featuregated-crd-manifests.yaml
• config/v1/zz_generated.swagger_doc_generated.go
• hack/update-payload-crds.sh
• payload-command/empty-resources/0000_05_config-operator_02_criocredentialproviderconfig.cr.yaml
• payload-manifests/crds/0000_10_config-operator_01_criocredentialproviderconfigs.crd.yaml

💤 Files with no reviewable changes (1)

• hack/update-payload-crds.sh

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Remove the feature-gate annotation if this API is GA.

Line 22 still gates the v1 resource behind CRIOCredentialProviderConfig. That conflicts with the GA objective and can keep CRD exposure conditional instead of unconditional.

Proposed fix

-// +openshift:enable:FeatureGate=CRIOCredentialProviderConfig

📝 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

// +openshift:enable:FeatureGate=CRIOCredentialProviderConfig

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@config/v1/types_crio_credential_provider_config.go` at line 22, Remove the
feature-gate annotation that gates the v1 API by deleting the line containing
"+openshift:enable:FeatureGate=CRIOCredentialProviderConfig" in
types_crio_credential_provider_config.go so the v1 CRD is unconditionally
exposed; after removing that annotation, regenerate any CRD manifests or API
docs (e.g., run the project’s codegen/make target) to ensure the CRD and
generated artifacts no longer include the FeatureGate metadata.

[openshift-ci-robot]

@QiWang19: This pull request references OCPNODE-4125 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.

Details

In response to this:

Upgrade v1 type CRIOCredentialProviderConfig, manifests, and corresponding empty resource for API GA in 4.22.

API type definition keeps the same as v1alpha1 CRIOCredentialProviderConfig

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.

[QiWang19]

@JoelSpeed could you help review this PR? Since in the feature https://issues.redhat.com/browse/OCPSTRAT-2853 we targeted GA of this API in 4.22, we haven't done other implementation outside of o/api, so moving to v1 now won't break any external dependencies.

[openshift-ci]

@QiWang19: 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.

[JoelSpeed]

we haven't done other implementation outside of o/api

@QiWang19 Before we promote a type to v1, we expect it to be feature complete and be in a state to demonstrate the feature is ready for promotion. Based on your comment, it sounds like we aren't there?

Before merging a PR like this, I'd expect to see a feature promotion PR with good data showing we are on track to have the required tests and pass rate soon

[QiWang19]

@JoelSpeed The feature is still in progress, not ready for promotion, which is why it's currently under a TechPreview featuregate.

This PR is to update v1 API early to avoid breaking changes later, but lock the feature under TechPreviewNoUpgrade featuregate. I intended to provide the test pass rate and promotion data when we actually promote the FeatureGate to GA.

I was under the impression that the test pass rate are requirements applied to the featuregate promotion rather than the initial addition of the v1 API type itself.

[JoelSpeed]

We don't want to ship v1 types under tech preview in case we need to change the types later as we learn something during implementation.

The normal path here is that you get the feature implemented in tech preview as v1alpha1, demonstrate it's working, and then we submit a handful of PRs to move the types to v1 once we are confident in the release it will ship GA in