feat: add account verifier url config

[mfrancisc]

generated from: codeready-toolchain/api#504

Summary by CodeRabbit

• Chores
  • Enhanced registration service configuration with support for account verification settings and updated field organization.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: cbe4229a-ea3b-4f89-ba9c-dc052cc39914

📥 Commits

Reviewing files that changed from the base of the PR and between 251ea71 and 8c548fd.

📒 Files selected for processing (1)

• config/crd/bases/toolchain.dev.openshift.com_toolchainconfigs.yaml

📜 Recent review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: test
• GitHub Check: GolangCI Lint
• GitHub Check: govulncheck
• GitHub Check: Build & push operator bundles & dashboard image for e2e tests

🧰 Additional context used

📓 Path-based instructions (1)

**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

• config/crd/bases/toolchain.dev.openshift.com_toolchainconfigs.yaml

🔀 Multi-repo context codeready-toolchain/toolchain-common

Linked repositories findings

codeready-toolchain/toolchain-common

• RegistrationServiceOption helpers and setters reference registrationService fields, including DisabledIntegrations:

  • pkg/test/config/toolchainconfig.go:234-287 — defines RegistrationServiceOption and methods; DisabledIntegrations setter writes to config.Spec.Host.RegistrationService.DisabledIntegrations (RegistrationServiceOption.DisabledIntegrations) [::codeready-toolchain/toolchain-common::pkg/test/config/toolchainconfig.go:234-287].
  • Many RegistrationService-related option setters reference nested fields (Environment, LogLevel, Namespace, Replicas, RegistrationServiceURL, Analytics, Auth, Verification, etc.) — these indicate consumers expect the registrationService spec shape [::codeready-toolchain/toolchain-common::pkg/test/config/toolchainconfig.go:239-554].

• Tests/assertions referencing registration service status/types:

  • pkg/test/status.go — multiple helpers that assert RegistrationService status and substructures (Deployment, Resources, Health, RevisionCheck) [::codeready-toolchain/toolchain-common::pkg/test/status.go].

• No occurrences found of the new accountVerifierURL field:

  • Search for "accountVerifier", "accountVerifierURL", or similar returned no matches in this repo — meaning consumers here will not automatically use the new spec field and tests/helpers may need updates if behavior relies on it [::codeready-toolchain/toolchain-common::search-results].

Summary assessment:

• The repo contains code that constructs and asserts ToolchainConfig.ToolchainConfig.Spec.Host.RegistrationService (including DisabledIntegrations). The PR's move/add of DisabledIntegrations likely aligns with these consumers, but field relocation in the CRD shouldn't break these usages because they reference the same JSON path; verify marshalling/unmarshalling remains the same.
• The newly introduced accountVerifierURL is not referenced here; if host-operator (the PR source) expects consumers to populate or read this field, downstream repos (like this one) won't be using it until updated.

🔇 Additional comments (2)

config/crd/bases/toolchain.dev.openshift.com_toolchainconfigs.yaml (2)

162-165: accountVerifierURL schema addition looks good.

This is correctly added under spec.host.registrationService and is consistent with the existing schema style for URL-like config fields.

---

212-220: disabledIntegrations definition is correctly modeled.

Array item typing and x-kubernetes-list-type: set are appropriate, and the field remains at the same schema path for compatibility.

---

Walkthrough

Updates a Custom Resource Definition (CRD) schema to add a new accountVerifierURL string field to the registration service configuration and relocate the disabledIntegrations array field to an earlier position within the same configuration block.

Changes

Cohort / File(s)	Summary
CRD Schema Update config/crd/bases/toolchain.dev.openshift.com_toolchainconfigs.yaml	Added spec.host.registrationService.accountVerifierURL field and reorganized disabledIntegrations array placement within the registration service schema.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Suggested labels

feature

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat: add account verifier url config' directly and clearly describes the main change: adding a new accountVerifierURL configuration field to the CRD schema.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Review rate limit: 8/10 reviews remaining, refill in 10 minutes and 28 seconds.}

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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexeykazakov, metlos, mfrancisc

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:

• OWNERS [alexeykazakov,metlos,mfrancisc]

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